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A3S TRACT 



A design for a secure. multi-user. Tile Storage System 
is developed. This design. incorporating a concurrently 
developed Security Kernel, provides a multilevel secure 
flexible file storage serving a distributed system of 
dissimilar computers. The Security Kernel is responsible for 
non-discret i onary (e.g. , classification and clearance) 
security and the T ile Storage System Supervisor is 
responsible for discretionary (e.g., "need to know”) 
security. Multilevel security is achieved by the controlled 
access to consolidated file storage for Host computer 
systems. Multiprogramming of surrogate Supervisor processes 
operating on behalf of the Host computer systems provides 
for system efficiency. * segmented memory at the Supervisor 
level allows controlled data sharing among authorized users. 
System integrity is independent of the internal security 
controls Cor lack of them) in the distributed systems; the 
Tile Storage System prevents system-wide security side 
effects. A loop free structure along with system simplicity 
and robustness are design characteristics. 
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I . INTRODUCTION' 



Lac’- r of data security is a central issue in computer 
science today, ^ata security car. be divided into external 
physical aspects (i.e., guards, fences, etc.) and irt°rnal 
system aspects 'i.e., internal software and hardware 
operations''* both of which are necessary for effective 
system security. The physical aspec* is understood and does 
not pose a significant problem today. Continued loses (viz., 
money, data' die to computer ’error’, illustrate that the 
second aspect of data security. vi7., internal security, has 
not been solved and continues to be a problem. 

Thi ^ sh c r t corr'i rj results from the fact that internal 
computer security has not beer, a mandatory design objective 
during hardware and/or software selection and/or production 
in most (if r, ot all) cor tempera rv computer systems. This 
renders them prone to security violations from ecciiential 
or malicious penetrations [Schell(l)]. Ad hoc attempts to 
provide the necessary system security in the later stages of 
the system design or implemer tat ion have r ot generally met 
with success. 

In contrast, this thesis presents a design for a 
multilevel secure computer operating system, the File 
Storage System iFSS) in which internal computer security is 
a primary design objective. There are two goals this system 
is designed to achieve: 1) to provide sharing of data among 
authorized users ard, 2) control access to a consolidated 
’warehouse" of data. This controlled access to consolidated 



network for the system structure 



data, predicates a "star 
as depicted in figure 1. It must be noted, however, that the 
ESS carrot control the physical security cf the Host systems 
and that TT ost systems have the ability to circumvent ESS 
security by direct irter-Host communication links. To 
preserve data security, all accesses to the ESS consolidated 
data must mo through the ESS for access validation. 

Data sharing amonm authorized users is accomplished by a 
segmented environment which allows controlled direct access 
to all on-line data. The Security Kernel (or simoiv Kernel) 
is used to insure that nor-dis cret i ooary data access is 
performed in an absolutely controlled (i.e., secure) manner. 

See [Cclemanl for detailed information cn the Securi*y 
Kernel . ) 

I 

A. PP.C3LSM DEFINITION 



'it is illogical to ignore the fact tnat computers may 
disseminate i^formatior to anyone who knows how tc ask for 
it, completely bypassing the exuensive controls rlaced- on 
paper circulation." [Schell (1)] 

That this fact is ignored is demonstrated cy the 
estimated 100 million dollars lost yearly by non-secure 
computer systems ir the United States [Denning(2 )] . It is 
obvious that a primary problem/limitation of computer 
systems in use t oday is the lack of data security. As 
recuirements to store and access data by computer increase, 
the seriousness of this protler/limitstion cannot ce 
ignored . 

A system that can simultaneously provide data at 
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Figure 1. Systen Ccnfiruraticn 
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different sensitivity (viz., "classification') levels for 
users with different access authorizations (viz., 

" clearan ces " ) without a security violation is said to be a 
multilevel secure system. "Because it is usually not 
•desirable to authorize all system users access to the 
highest level of data f 'system high’) or provide separate 
(without sharing) systems for each level of data, a 
multilevel system is highly desirable. \ multilevel system 
also allows the maximum amount of controlled data sharing 
amors authorized users, a primary »oal of any data storage 
system. 

Previous research shows that a viable approach to the 
auestior. of internal computer security exists. This 

approach, sometimes termed the "security kernel approach 
[Schell^ 2)], was introduced by Schell in 13?2. It gathers 
into ore module all elements that effect the system 
security. The module, by being restricted in size, can be 
verified correct which in turn allows the total system to be 
certifed secure. 

The ?SS software is composed of the Supervisor and trie 
Kernel. It will provide a multilevel secure consolidated 
file storage for distributed Host computer systems. The 
non-discret ionary security provided by tne Kerrel and the 
discretionary security provided tv the Supervisor will 
implement a wide range of security policies, including the 
standard Department of Defense 'DOT) security policies. Data 
sharing is achieved by a segmented memory environment at the 
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Supervisor level. The Supervisor uses segments ''invisible to 
the Host systems) to construct the Host files. Multilevel 
security is achieved by the management of files submitted by 
the Host systems which e^ist at distinct security levels. 
This allows the construction of a multilevel secure system 
which is dependent on only one secure element of the 
^SS — the Kernel. 

3. BACKfxHOUNE 

The dramatic reduction in size and cost along with the 
increase in performance of microprocessors in the last 
decade has made their use feasible in areas that have 
previously bee” reserved for rixri/rrgya computers (or ret 
computed at all). Whereas security has been notoriously 
lacking i” the larger systems, it has been no^-existent i r 
microprocessors to date. 

3ecause of their small siz°, low cost, durability, ard, 
perhaps most importantly, the manpower savings induced 'just 
to mention a few of rany advantages), microprocessors have 
high appeal for use in a military environment. However, the 
military alsc has an obvious need for security within their 
computer systems, whether they are micro, mini, or maxi 
ba s ed . 

For example, the Navy is presently considering systems 
for the ne^ t generation of non-tactical shipboard computers 
[Smith]. They will be mainly used for data processing in the 
areas of: 
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Pay and Personnel 
Supply and Finance 
Maintenance . 



Cost. siz° a^d speed constraints will sccr be met by 
commercially available products. Security, however, 
continues to op a problem not adequately addressed in any 
available systems. To preserve data confidentiality (not 
only with respect to clearance level but also with respect 
to the current stipulations of the Privacy lot), security is 
a necessary cart of any shipboard computer system. Fay 
records. for example, should not have the same access level 



as maintenance 


records. In 


order 


t 0 


store records m 


a 


common data 


base and to 


have 


con 


trolled sharing wh 


en 


aopropriate , 


the computer 


mus t 


be 


able tc maintain 


a 



multilevel s ecu re environment. 

There are several possible approaches to achieve a 
secure multilevel environment. The frontal appro c oh , which 
is most difficult, is to certify all distributed computers 
which have access to the data base as secure. : second 
method and the method adopted for the ^SS , is to cerfify 
only one eleme r '*- of the F55 secure — the Security Kernel, ill 
access to the ^SS that involves non-discretionary security 
will be validated by the Kernel. The FSS therefore 
guarantees to manage files in a manner consista.it with the 
FSS security policies. 

The design for the ”SS is one mem be ^ of a family of 
systems proposed by O'Connell and Richardson [O'Connell]. 
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Security, configuration independence, and a loon-free 
structure ar-p characteristics of this family of systems. 

C. BASIC DEFINITIONS 

1 . Securi ty 

'lthough any viable secure system includes both 
internal and external aspects, relying excessively on 
external controls is not desirabl 0 in many cases due to the 
added expens°s and increased security risks involved in 
error-prone manual procedures. External controls also cannot 
provide the secure sharing of data that is needed in such 
applications as intearated data bases and computer networks, 
primary characteristics of the FSS . The use of the Kernel 
concept is a demonstratively effective and practical method 
for providing the internal computer security controls that 
are necessary for a secure multilevel system. This concept 
is at the center of the FSS desian. 

The basic cor cep I behind this approach is that a 
small oortion of hardware/software, the Kernel, can provide 
the internal security controls that are effective aaainst 
all attacks, (malicious or accidental) including those never 
thought of by the designer. (This also means that errors in 
the FSS Supervisor cannot cause unauthorized access to 
data . ) 

System security is the implementation of a security 
policy. This nolicy is a collection of lav/s, rules, and 
regulations that establish the rules for access to the data 
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in the system. Such policies, such as the one established by 
the DO . have two distinct aspects: discretionary and 
r_or.-discretior.ary security. Mon-discretionary security 
e T ternally constrains what access is possible. Ir. the DO D 
environment, the familiar non-discret ionary security levels 
are* top secret. secret. confidential, ar.d unclassified. 
Since most contemporary computer systems do not provide the 
data labeling necessary to support non-discreticnary 
security, all data is implicitly accessible. In the ?SS, 
seamen ta ti or allows ur.ioue identification and labeling of 
data; nor.-discnetionary security is therefore supported. The 
Kernel is the one elemert in the FS3 responsible for 
erf ore ins con-discretionary security. 

N on-di sere t i onary security involves the comparing of 
the access class of a specific object (object access class, 
(oac)) with the access class of the reouestor (subject 
access class, 'sac)) to insure compatibility. In a DOD 
environment, for example, a person (subject) with sac of 
secret has access to files ^objects) at any access class 
eaual to or less than secret. The relationships between 
different access classes are represented by a partially 
ordered lattice structure [Denning 1 ) 1 . This lattice 
represents the authorized access based or. the relationships 
of two levels. An example of the not-related (making; the 
lattice partially ordered) relationship, occurs because of 
DOD compartme’i tali zation (e.g:., secret is not related to 
sec re t .nuclear ) . The following accesses are permitted for 



the relationships represented by this lattice structure. 



sac 


=: 


oac 


tread /write access 




sac 


> 


oac 


tread access ( read down) 




sac 




oac 


twrite access (write up) 




sac 


O 


oac 


:no access (sac not related 


to oac ) 


In 


eac 


h 


case, the Kernel must 


know the 


cat i on 


of 


the Host system if it is 


t r perf err 



correct non-di scretionary security checks. Unique system 
identification is provided hy the system pert number, which 
is hardwired, and known to the kernel. 

Dis c r° t i o^ ar y security provides a refinement to the 
non-di sc ret i or.ary security policy and is reflected in the 
DOT "need to know" policy. Computer systems which have 
- c c e s s Control Lists ('ACL' 1 associated with data, implement 
this discretionary policy. The 755 Supervisor is responsible 
for the System discretionary security and although this 
aspect of the System security is not validated by the Kernel 
(and therefore rot certified correct), the validity of t*e 
non-di sc ret i onary security is not affected. 

To implement its 'aspect of security, the Supervisor 
needs to know the identification of the Host system "user". 
This Host system user identification must be passed to the 
?SS Supervisor by the Host system. Since an insecure Host 
system cannot be trusted to pass the correct information, 
the user identif ication is only as frood as the Host system 
implementation, (i.e., ^SS discretionary security is only as 
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good as the Host System's implementation of discretionary 
security.) This implementation may be good or. some systems, 
(e.g., UNIX [Morris]) but non-existent on other systems 
fe.g., CP/M [Digital]). It must be remembered that this in 
no way affects the enforcement of the r.on-dis creti onary 
security by the Kernel. 

2 . Process 

1 process can be described as a locus of execution. 
The collection locations that may be accessed during this 
execution is known as the process' address space [Madnicg] . 
a process also has the characteristic that it may be 
executed in. parallel with other processes, enhancing system 
efficiency and allowing the separation, of tasks into 
different processes for design clarity. 

The FSS has two processes per Host system. These are 
ar. irput/output (10) process for Supervisor to Host data 
transfer and communication and a file management (PM) 
process tha t controls and maintains the Supervisor file 
structure. Interprocess communicati on is achieved by the use 
of even tcount s , sequencers, and s ynchroni ?a ti on primitives 
internal to the Kernel (described later). 

3 . Segmentation 

Segmentation allows for the direct addr°ssing of all 
system on-line information and the application of access 
control to this i r f c rna t i on. . Note that direct addressing 
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ices not mean random access to the on-line information. On 
the contrary, access to s egmer ts is controlled cy explicit 
memory management calls to the Kernel to swap in/out a 
segment. A segment can he defined as a logical grouping cf 
information such as a subroutine, procedure, data area, or 
file. Each processes' address space consists of a collection 
of segments. In a segmented environment, all address space 
references reauire two components, a segment specifier and 
an offset within that segment. Segmentation is used to 
provide the Supervisor domain of each process a virtual 
memory of limited size. Segments, as mentioned earlier, are 
used by the Supervisor to construct the Host files which 
retain the attributes of segment, s 1 i . e . , access control). 

4. Mu Itl pregranmin g 



1 mul ti pr ogrammed environment is one in which more 

4 - 

than one process is in a state of execution at the same 
t ime . These processes share oroce ss or tine, memory , and 
other resources among the active processes. In the design 
for the KSS , the Supervisor processes are multi programmed in 
an asynheronous manner for system efficiency. A 
multiprogramming environment allows the Host systems to 
operate in a logically parallel manner which adds to System 
design simplicity and clarity. 

5 . Protection Domains 

One of the l-cey elements necessary for valid Kernel 
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implementation is the isolation of the Kernel from all 
possible outside influences. This can be done through the 
use of protection domains. 

Protection domains are used to arrange process 
address spaces into "rings’’ [Schroeder] of different 
privilege. This a^ra’ire^ent is a hierarchical structure with 
the most privileged domain being the inner most ring. Figure 
2 represses the 'inf organization in the t S3 . 

Protection rings may be created by either hardware 
or software. Hardware is more efficient but is rot 
commercially available in microprocessor devices today. Two 
state devices are available, however, ard by implementing 
the two states as sera rate rings and providing for software 
ring crossing mecha^is ins , the necessary two protection 
rings can be created. 

D. SYST2M RECCJI R2MINTS 

There are no fixed hardware reouirements for the 
implementation of the FSS . System efficiency ioes, however, 
depend on ar. appropriate choice of hardware. Two basic 
hardware features that are felt to be necessary for a viable 
implementation of the FSS are segmentation and multiple 
doma ins . 

Segmentation is necessary for access control a^d data 
sharing, a multiple state ' two in this case) is necessary 
for the isolation of the Kernel from the remaining (and 
uncertified) software. 
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Figure 2. Protection Domains 
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Only the Kernel has access to 



mac nine 



instruction 
provides a 
opera t es . 
environm ent 



privilege! 

s and controls all system input/output . It 
segment 3 ! environment in which the Supervisor 
The Supervisor in turn, provides a virtual file 
for the ^ost computer systems. 
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II. EES IGN 



A. FA RE WART S TLT-TI OM 

A secure computer system is rot dependent or the 
hardware or. which it is implemented. However, as nentiored 
above, segmentation and multiple donairs are considered 
necessary for 7 SS efficiency. 

Segmentation allows the use of one uniform type of 
information object, the segment, at the Kernel level. This 
simplifies Kernel design, and contributes to keeping Kernel 
size small. A segment address consists of a segment name and 
offset within the segment. Although this addressing can be 
done in software, it is faster and more efficient when done 
in hardware. Hardware can also simultaneously check for 
authorized access, a necessary feature of a secure system. 

Multiple d^p-airs are currently used in some of the 
larger machines to protect the operating systems from the 
applications programs. Multiple domains have not, until 
recently, been available in a microprocessor configuration. 
The TSS design reauires only two domains, ore for the Kernel 
and one for the Supervisor. 

The introduction of the Zilog Z8000 series 
mi cr ouro ces s or meets both the segmentation ard multiple 
domain recui rement s . The FSS is targeted for implementation 
on the Z8001 segmented microprocessor [ZilogfR)] with its 
associated Memory Management Unit ( MMU ) [Zilog'l)]. The 
Z8A01 is a 15 bit two-domain machine which produces a 23 bit 
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logical address. The Z?01? MMU maps the 23 hit logical 



address into a 24 hit absolute address and allows the 
capability of addressing up to 128 segments (with two MMU's) 
of 64K bytes each (SM-bytes total) in a two-dinensior.al 
memory space. (See [doleman] for further details.) PS-232 
bus compatibility is assumed for serial data in put/out put at 
the hardware level. This allows byte synchronization and 
byte parity checks to be performed at the hardware level by 
the ESS universal asynchronous receiver-transmitter (UAPT). 

8. SYSTEM STRUCTURE 

1 . System Levels 

Abstraction is a way of avoiding complexity and a 
mental tool for approaching complex problems [Uijxstra 2)]. 
The use of abstaction allows the presentation of a system 
design that is concise, precise, and easy to understand. 
There are four levels of abstraction for the F35 as 
presented in figure 3. 

Level ? is the hardware level a^d consists of the 
Z80C1 microprocessor memory and some form of disc storage 
{initial implementation nay be with floppy disc). 

Level 1, the Kernel, is isolated and protected from 
manipulation 'accidential or malicious) hy beiog placed in 
the more privileged domain of the Z8001. Only the Kernel has 
access to ’’system’’ machine instructions and controls all 
access to the system hardware elements ''memory, disc). The 
Kernel provides a segmented environment in which the 
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- i ata 
control 



'i.e., communication ) 



Figure 3. Abstract System View 



Supervisor operates. 



Level 2, the Supervisor, operates in the outer (less 
privileg°d) domain of the Z3201. It has access to "normal'’ 
machine instructions, but must go through the software 
Gatekeeper [Coleman! of the Kernel to get access to memory 
(viz., segments) and disc storage. The Supervisor provides a 
virtual file hierarchy to each Host system for file storage. 
In order to manage the file hierarchy, surrogate processes 
( input /output (10) and file management (FM)) are assigned to 
each n ost system. These processes act on the reouests 
submitted by the Host computer systems. .^11 processes are 
created at system generation time and are not created or 
deleted in a dynamic manner. 

Level 3 consists of the Fost commuter systems. These 
systems a^e hardwired to the ZS201 in the FSS design. Each 
port has a fixed access level so that if a multilevel secure 
Rest desires + n handle data at two levels, it must have two 
connections to the ^SS. (Mote that if the Rost is not a true 
secure multilevel Host, and dees have multiple connections 
with distinct levels, then the FSS security constraints are 
ci rcum vented . ) 

2 . System Protocol 

Protocols are formal specifications which constrain 
data exchange between systems and the FSS. These 
specifications allow the FSS to achieve bounded, deadlock 
free and fault tolerant communication. To organize and 
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simplify protocol design in the FSS , protocol is logically 
divided into a hierarchical structure of two interacting 
layers. Level 1 protocol handles packet (described later) 
synchronization, enror detection, and command type 
determination. Level 2 handles the repetitive activity of 
data transfer. 

Data and commands are transmitted between ^SS and 
Host via fixed size packets. Packet synchronization is 
necessary for Host-FSS communication. Error 
detection /correct ion is closely related tc the problem of 
packet synchronization; packets not in synchronization will 
not be correct. The co r verse is not true, however. A 
synchronized packet may contain transmission errors. There 
are several methods f n r error detection/correction 
[Hamming] . A design choice of a simple check sum per packet 
•'to detect packet errors) was made in the interest cf S vs ten 
simplicity. If an error is detected in a packet, the Host 
will be rec nested to stop packet transmission and to begin 
again with the packet in which the error was detected. Cf 
course, the FSS must be able to provide the same service. 
This retransmission upon error detection strategy, combined 
with the byte parity checks performed at the hardware level 
by the UAET, will provide the error detection/correction 
scheme in the initial FSS design. 

3 . Host Environment 

The job of the FSS is to provide a service, viz., to 
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store files in a secure 'data warehouse’. The files are 
submitted by various Host computer systems. The virtual 
environment provided the Rost systems is therefore a primary 
design consideration of the overall FSS design. Design goals 
are to make this Host environment simple, easy to use and 
understand, efficient and robust. 

The center of the Host environment is the 
hierarchical file structure maintained by the Supervisor of 
the FSS. This file structure is a tree organization which 
facilitates design abstraction (virtual file systems per 
Host) as well as file system searches via tree traversal. 
Figure 4 illustrates the overall logical structure of the 
Supervisor file system. 

A file can be defined, in the case of the FSS, as 
one or more Supervisor segments grouped together for the 
purpose of access control ^security), retrieval (read), and 
modification (write) [Shaw]. In the FSS the file is the 
basic unit of storage at the Host system level. 

The hierarchical file system contains two types of 
files: 1) data files, and 2) directory files. Both file 
types are constructed from segments (invisible to the Host 
systems) at the Supervisor level. The characteristics 
usually associated with a segmented environment (Supervisor 
level) such as data sharing and access control, are 
transferred to the file environment (Host level) by the FSS. 

The Host system environment consists of a virtual 
file hierarchy maintained for each Host system (i.e., one 
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virtual file system per hardware port). A primarv reason for 
having multiple virtual file hierarchies is to avoid the 
problem of naming conficts which would eventually occur in 
the Supervisor hierarchy as the system grew if per-host 
virtual file systems did not exist. Multiple directories 
also allow the Host systems to group related files into one 
directory, simplifying search and Host use. The Supervisor 
will control the duplication problem within a virtual file 
system by not allowing duplicate file names in a single 
directory file. Pathnames are required to uniquely identify 
files in the Supervisor file systems and must be included in 
the Host reauest . 

Access to the Supervisor file hierarchy is 
controlled in both a discretionary and non-d i screti onary 
manner. The non-discretionary access is controlled by the 
Kernel which will prevent a Host system from reading up or 
writing down (confinement property). Discretionary access to 
the files is handled by the Supervisor which compares the 
Host. user ''Host use 1 * combination) with the file ACL. 
Reauestei access is permitted only if the Host. user is 
explicitly permitted access by the file ACL. 

Pach Host system virtual file hierarchy is 
constructed from data files and directory files which, as 
mentioned above, are constructed of Supervisor segments. 
Although dynamic growth and shrinkage are usual segment 
attributes, a design choice for System simplification was 
made to fix segment size at three increments, SMALL (512 



bytes), ^FDIUM ( 2K bytes), ani L 4 R(J? ( SK bytes). These sizes 



were chosen as a compromise between expected file sizes, 
Supervisor buffer reaui rements , and minimizing the number of 
software ring crossings that would be reouired during a data 
file 'read' or ’store’ operation. Because segment size is 
limited and there exists the likelihood of encountering 
files larger than the maximum segment size, the concept of a 
multiple segment file (msf) is known to the Supervisor. 

Figure 5 deoicts the general tree structure of a 
Supervisor virtual file hierarchy. Directory files are 
represented by sauares and data files by circles. Data 
files, as their name implies, contain data only. Directory 
files are constructed of a header and zero or more 
"entries”. There are two types of entries, branch entries 
and link entries. 

Branch entries contain the attributes of the file 
which they identify. In figure 5, for example, the 
attributes of directory file User_l 'entry name, ACL, size, 
type, etc.) are contained in directory file Hcst_l, brar.ch 
entry User_l. One branch entry designates one Supervisor 
segrcen t . 

A link entry, represented by the dotted line ir 
figure 5, is composed of an "entry name" (link name) ar.d a 
pathname. (A pathname is the concatenation of entry names 
starting from the root directory and proceeding ir. 
seouential order to the specified file.) Like a branch 
entry, a link entry is used to access a specific file. For 
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example, ir. figure 5, the pat'nrame contained in the link 
entry is Hos t_i>User_3>Bir_l . Unlike a branch entry, 
however. the link entry does not contain any file 
attributes. Access is controlled as tne Supervisor traverses 
the specified path to the requested file. 

The use of link entries allows sharing of files 
among Host systems and among Host system users. Locos which 
mi^ht be venerated by two links which reference each other, 
are prevented by the Supervisor. (Loons could present a tree 
traversal problem to the Supervisor.) 

Each file has a file name (E.ntry_Mane — uniaue per 
directory file) given by the Host system at file creation 
time. This file r.aoe and its oathname are used to ur.iouely 
locate the file in the Host's virtual file system. 2y 
traversing the virtual hierarchy, the Suoervisor can locate 
the reauested file if it exists in the system. In either 
case (viz., whether the file exists or not), aonrooriate 
action can be taken by the Supervisor. 

a. Directory File 

Figure 6 is a logical representation of a file 
directory. Each directory file is made up of a header and 
zero or more fixed size branch/link entries. A fixed 
directory size of LAHUE (SK bytes) was chosen to insure a 
reasonalble amount of directory space for Host system use. 
This could nose a "suace" problem, especially for secondary 
storage. (Adequate main memory can be installed for required 
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' Header ) 

En t ry_Cou ,n t-1 "byte 
*ri, Count-? bytes 



f B T- anch_Er. t. ry ) 
T 'ntry_Nane-l G bytes 
3ranch_Lirk_Svi tch-1 "byte 
a CL_P t r-2 bytes 
’ r ile_Size-4 bytes 
Da + a_Di r _S wi t ch-1 byte 
r ile_Created — IP bytes 
Las t_Update-15 bytes 
Access Class-1 byte 



( Link_Er. try' 

E^try Namp-lS bytes 
Branch_Lirk_S witch-1 byte 
Link-128 bytes 
Li *k Created -16 bytes 



■Pigure 6. Loeical Directory Structure 
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buffer space.) The Kernel, which stores segments as pages, 
rray want to ’compact' segments by not storing or. secondary 
storage pages which contain all "oeros". This would greatly 
reduce the amount of wasted space on secondary storage. 
(Another enually viable solution, but not s°lected for this 
design, is to have multiple segment directories in the 
Supervisor similar to multiple segment data files.) The 
directory file header contains the following information: 

£ntry_Gount : This is the number of brar.ch/link 

entries in the directory. 

ACL_Count: This is a count of the number of 
ACL_ENTEY elements left in a "pool" of such elements. 

If the entry is a branch entry, it will contain 
the following eluents: 

T 'ntry_Name: ^ntry name is the file name. The 
Host systems a^e responsible for supplying these names but, 
as mentioned above, will be prevented by the Supevisor from 
having duplicate names (file names) in ore directory file. 

Ac ce s s _C 1 as s : This °lement contains t^e file 

access 1 evel . 

3ranch_Link_Swi tch : This element will identify 
the entry as a branch entny which in turn specifies the 
entry format. 



ACL_Ptr: This e 


lemer.t will 


poir t 


to an 


ACL 


for 


the branch entry. The 


?SS has 


only 


three 


d ist 


i n c t 


discretionary access modes: 


. »* »» 
1) null 


access 


as 


>< 0 


n a t e 


implies, declares that no access is 


t o be 


allowed to 


the 
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specified Host. user combination, 2) ’read’ access allows a 
Qualified Host. user to read a file only (i.e., no write 
access), 3) "write" access allows a Host. user write access 
to a file (also implicit read access). The actual ACL will 
be a list of authorized users ir the form Host. user with an 
associated access mode. k 'don't care’ authorization (in 
this case a , will allow general access in that category. 
v ov example, *.user would allow the specified ’user’ to 
access this file from any connected Host, system with a 
specified access mode. This ACL for entry "user" can easily 
be expanded to include other categories such as ’pro/j°rt" to 
further refine the discretionary access allowed to a file. 

File_Size: This information is necessary for 
proper management of the Host R2AE'_FILI and 3TCRT_FILH 
commands by the Supervisor, viz., it allows the Supervisor 
to calculate the number of se^ents that make no a multiple 
segment file. It will be supplied by the Host system in t v e 
STGRS_IILF command reouest 'in bits). 

Da ta_D ir _S w i t ch • This switch tells the 
Supervisor the type of file to whi oh the branch po lots 
■data, directory). This is necessary due to the different 
file formats. 

Fi le_Crea ted : This element is used for general 
audit purposes, i.e., to have a permanent record of the file 
creator and the time of creatior. 

Last_Updatet This elem°nt will identify the last 
Host and user to store into the file. This identification 



will be of the form Hn?t.us°r .date. time. This will allow the 



FSS to have a limited audit capability. The confinement 
property prevents the FSS from also keeping track of read 
accesses since processes at higher levels can read at lower 
levels hut cannot write r he audit information. Also n ote, 
that the Last_Update information for upgraded directories 
nay r.ot he accurate for the sam p reason. 

If the entry is a link entry, it contains only 
four elements. These are: 1) Entry_NIame to identify the 
file, 2) ?ranch_Link_Swi tch to identify the entry type, 3) 
Link, a pathname to uriouely identify a file, and 4) 
Create _Time , the time of link initiation alon<? with the 
Host. user who created the link. All attribute checking is 
done as the Supervisor traverses the specified path. 

A FSS design choice is to limit all pathlergths 
to 12S h yte s . This places some restrictions on the Test in 
that long file names will socn consume the bytes available 
for a pathname. However, this restriction can be overcome by 
pathnames which contain several link entries, which can 
themselves be 128 bytes, kith 32 branch/link entries per 
directory, there are an average of 32 ACL entries (3 bytes 
each) available to each branch entry. < Remember ,lirk entries 
do not have ACL entries.) Figure 5 contains the initial 
field sizes for the directory construction. The primary 
factor in calculating the size of branch/link entries is the 
size of the link pathname. This increases the size of li^k 
entries to 163 bytes and although space is wasted in branch 



3T 



entries, the simplification of System design resulting from 
a fixed size of b ranch/ link entry is felt to he sufficient 
justification, in the initial design. 

t. 'Data ^iles 

Data files are always ’’leaf ' nodes in the file 
hierarchy and contain only data. 

c. Multiple Segment File Directory 

A msf directory is a Supervisor construct 
(invisible to Host systems) to manage files larger than the 
maximum fixed segment size. Because the number of segments 
that will be reouired by the Supervisor to store a file can 
be calculated from the file size information passed by the 
Host, a msf directory need orly be a segment of size zero. 
This na’xes the Kernel alias table (which is a fixed 
size — see [Coleman! ) the limiting factor in the maximum file 
size. The alias table has the seme number of entries as a 
Supervisor directory (viz., 32) which limits mari^um Host 
file size to 25 C K bytes. Files that exceed the maximum file 
size must be split by the Host system. , Sti attempt to store a 
file that is ’too’ large will result is an error condition 
response to the Host and an unexecuted compand. 

4 . Host System Commands 

The Host commands orovide the only interface that a 
Host system has with the FSS . Each command is interpreted by 
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the FS5 and acted upon by surrogate Supervisor processes? 
the Post system has no direct access to the FSS. There is 
one acknowledgement between the Host and FSS at this level. 
This is a "command complete" acknowledgement that informs 
the Host system that the Supervisor has completed action on 
its reauest. If an error condition occurs, the appropriate 
error code is returned in the acknowledgement . 

s no ther as nee t of the Host environment needs to be 
defired also. The Host environment can be divided into two 
states? they are the "old" state, before the FS5 has acted 
upon the Host reauest, and the "new” state, which occurs 
after action has been completed by the FSS. The specific 
sta + e of the FSS at any instant is in determinate at the Host 
level if more than one Host is accessing the same file of 
the FSS at o^e time. That is, since Supervisor processes 
execute in a completely asynchronous manner, the FSS state 
may change after a Host command is sent but before the FSS 
acts on tne command. This will not affect the oerformence of 
the System or validity of its security? Host commands will 
be executed as a single, atomic operation in the FSS state 
in which they are received and interpreted. The Host will 
get some "correct" response for some state existing between 
the sending of the Host command and the FSS acknowledgement 
on the same command. This allows several Hosts to safely 
synchronize their actions external to the FSS. 

The following is considered to be a minimal subset 
of commands available to the Host System for adecuate file 
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control. Figure 7 illustrates the reauired discretionary 
access attributes. T^e files are referenced in the Host 
command descriptions starting from the root of the Rest 
virtual file system. The pathname specifies the parent 
directory file (containing access attributes of the file), 
and the file (data or directory) to which the ^ost command 
refers. All commands require a pathname for unique file 
identification. Each command also r°ouires the specification 
of the Host system "user" in order for the Supervisor to 
perform discretionary security checks. This ’userid’ will be 
supplied by the Host system or the Host system user, which 
ever is appropriate. 

C?.2ATE_FIL3 <pathname, access_class , file_type 
(directory. data)>. This command reauests that the 
Supervisor create a branch entry in the specified directory 
under the specified file name at the specified access class. 
Ar initial access mode of write will be given to file 
creator and may be altered by the use of the . S DD_? CL_ENTRY 
and DEL 3TE_ACL_ENTRY commands. This is the only Host command 
where file access class is specified. It is used in this 
command to create upgraded directory files, if desired. 
(Data files may not be upgraded — described later.) In the 
initial implementation (with single level Hosts), there will 
be no upgraded directories within a Host virtual file 
system. Initial data file size is zero! initial di rectory 
file size is LAR'IH (?K bytes). Actions taken: 

1) The Supervisor locates the root of the virtual 
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Figure 7. File Eiscreti onary Access Control 
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file system for this Host an I hoes a tree traversal to 
locate the parent directory file. 

2) If the parent directory file is not found or 
found but write access to the parent directory file is not 
allowed, ar appropriate error code is returned ("file not 
found' or ’write not permitted’). 

3) If the directory file is found, and room exists 
in the directory, the new file is entered in a branch. is 
mentioned above, no duplicate file names will be allowed by 
the Supervi sor . 

CRSAIT_LI^K ^pathname, li^k ,userid>. This command 
reauests that the Supervisor create a link in the specified 
directory under the specified file name. As already 
mentioned, the Supervisor will not allow links to form 
loops. This is done by restricting the maximum number of 
files in ore pathrame to s 4 files. (This figure is reached 
by allowing a maximum pathlength of 125 bytes and having 
file names of ore character. File name delimiters of one 
character, viz. will give a maximum pathlength of 64 
files.) By keeping track of the path traversed, the 
Supervisor is able to determine if and when a loop is 
formed. Actions taken: 

1) The Supervisor locates the root of the virtual 
file system for this Host and dees a tree traversal to 
locate the parent directory file. 

2) If the parent directory file is not found or 
found but write access to the parent directory file is cot 
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allowed, an appropriate error code is returned. 

3) If the parent directory file is found and room 
exists in the directory, the link is entered in a link 
entry . 

DELETE_FILF <uathname , useridb. This command 
reauests that the Supervisor delete the specified file from 
the virtual file hierarchy. For design simplicity, only 
terminal files (including msf's), can he deleted. This means 
that directories must be empty in order to be deleted.. 
Actions ta v e" : 

1) The Supervisor locates the root of the virtual 
file system for this Host and does a tree traversal to 
locate the parent directory file. 

2) If parent directory file is not found or found 
but write access to the parent directory file is not 
permitted, an aupropriate error code is returned. 

3) Otherwise, if the file is located, it is deleted 
by the Supervisor. 

READ_EILE -^pathname, command.. type (directory , data, 
size) ,userid>. This command reauests that the Supervisor 
trarsmit to the Host either a data file, directory file 
'selected elements only), or the Fiie_Size, Last_Update, and 
Access_Class Gentry data) elements associated with a 
particular file. An explanation of the last parameter, to 
transmit entry data only, needs some ex plai nation. 

?ranch entry elements can be logically divided into 



two categories with respect to discretionary security. The 
first category, which includes Tr. + rj_N'aoe, 
Branch_Lin' r _Svri t ch , Acces s_Class , a^d ACL_?tr are branch 
entry attributes which car.not be altered by a Host process 
unless the process has discretionary write access to the 
directory which contains the file branch entry. 

The second category, which contains File_5ize and 
Last_Update, are attributes which, ’belong’ to the file and 
must be updated when the file is updated. A situation nay 
exist where a process may not have ar.y discretionary access 
to a directory but may have discretionary read access to a 
file in the directory (ulus implicit access to the rest of 
the directory during the "search"). In order to read this 
file, the Host system will need to know file size in order 
to prepare to receive it. This is the situation where the 
?.F< S D_FILF (size) command is needed. Actions taken: (for data 
f ile ) 

1) The Supervisor locates the root of tb° virtual 
file system for this Host and does a tree traversal to 
locate the desired directory file. 

2) If the file is not found or found but read access 
to the file is not allowed, an appropriate error message is 
return ed . 

7>) Otherwise, the file is transmitted to the 
reauesting Host System. 

1 f or directory file) 

1) Same. 
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2) Same. 

3) If the directory file is found and read access 
allowed, selected elements of the branch/1 in.< entries are 
returned to the Host. 

(for file size) 

1) The Supervisor locates the root of th® virtual 
file system for this Host and does a tree traversal to 
locate the desired file. 

2) If the file is not found or found but read access 
to the file is not permitted, an appropriate error code is 
re turned . 

3) Otherwise, the File_Sire and Last_Update elements 
are returned to the Host.. 

ST0RE_?ILE <pathname, file_size ,userii>. This 
command reauests that the supervisor store the specified 
file in the FSS. Actions taker: 

1} The Supervisor locates the root of the virtual 
file system for this Host and does a tree traversal tc 
locate the data file. 

2) If the data file is not found or found cut write 
access to the data file not allowed, an appropriate error 
code is returned. Note that Host systems can store only data 
files; directories are ’built’ by the Supervisor. 

3) Otherwise, a store operation is performed by the 

FSS . 

READ_ACL ^pathname ,userid>. This command is used by 
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the Host systems in conjunction with the ADD_ a CL_ EMTPY and 
I' T 'I 1 !’T'5’_ACL_?NTRY to adjust (sive/reseind ) the access mode 
(read/write) allowed to a Host/Host user to a specific file. 
Actions taken: 

1) The Supervisor locates the the root cf the 
virtual file system for this Host and does a tree traversal 
to locate the parent directory file. 

2) If the file is not found or is found tut read 
access is net allowed to the parent directory file, an 
apuropriate error code is returned. 

3) Otherwise, the supervisor returns the file ACL 
for Host system user examination. 

ADD_ ACL_EMTRY ^pathname, ACL_Er.try ,userid>. This 
command reauests the Supervisor to add to the specified file 
ACL the specified a CL_Entry (Host. user comoina tior. plus 
associat°d access mode). a s with the orevious commands, the 
access is checked for correctness hy both the Supervisor and 
the Kernel before any action is taken. 

DZLETI_ a CL_ENTEY ^pathname, a CL_2n try .userid'*. This 
command reauests that an ACL_Entry be deleted from a file 
a CL. A-eain, aupropriate discretionary and non-di screti onary 
checks are made before any action is taken by the ESS. 

AEOET. This command reauests the Supervisor to auit 
execution of the present command and return the file system 
to its original state. There are only certain locations in 
the execution of Host commands that the Supervisor is able 



to interupt. If an ABORT command is received after an 
operation has teen completed but before the final Host 
acknowledgement is sent, the original command completion 
will be acknowledged and the abort command will be ignored. 
Otherwise, action of the command will be halted and the 
Supervisor will wait for another Host command. All Host 
commands (including ABORT) will be explicitly acknowledged 
with either a "command comolete" message or an appropriate 
error code. 

C. PROCESS STRUCTURE 

There are two Supervisor processes which act on behalf 
of each u ost system (hardware port). The input/cutput (10) 
process and the file management (FM) process. The 10 process 
is responsible for communication and data transfer (via 
packets) between the Supervisor and the Host system. The 
process is responsible for managing the per-Host virtual 
file systems and providing overall FSS control. All Host 
commands are interpreted by the FM process? the 10 process 
acts in a "slave" mode to the process. Acting together, 
the FM and 10 processes interpret and execute the file 
management reouests of the Eost systems. Kernel primitives 
READ, ADVANCE, AW*IT, and TICKET used in conjunction with 
eventcounts and seauencer (described later), are used to 
synchronize Host surrogate process execution. 

3oth the FM and 10 processes call on Kernel primitives 
to perform actual segment manipulation. The normal order ir. 
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which these calls are made is fixed by the Kernel design. To 
add a segment to a process memory, the order of Kernel calls 
is: 1) Gatekee per . Greate_Segment , 2) Gatekeeper . v !ake_Xaown , 
a n d 3) Gatekeeper .Swap_Ir. . To delete a segment from a 



orocess memory, 


the 


order of 


Kernel calls 


l s : 


1) 


Gatekeeper . Swap_0ut , 


2) Gatek 


ee pe r . Terminate , 


and 


3) 


Gatekeeper. Delete 


_Segment . The 


Suoervisor procedures 


use 



these invokation orders. 

There are three levels of abstraction for a Host 
surrogate process. They are: 1) the level at which Host 
commands are known. 2) the level at which files are known, 
a r d 3) the level at which Supervisor segments or rackets are 
known. These levels of abstraction should be keot in mind 
when readies the FM and 10 process descriptions. 

A design choice to simrlify file system maintenance and 
control is to allow upgrading of only directories (e.g., 
unclassified to secret). This will eliminate the possibility 
of having a secret file in an unclassified directory, a 
situation which would prevent updating of the file branch 
data by the secret, process sirce writing "down" is not, 
allowed. This restriction is not felt to exclude any 
significant FSS capabilities and provides for a simplified 
implementation . 

The modular construction of the FSS enhances System 
structure. All data bases, except the files themselves, are 
module local. Cod° is expected to be written in PLZ/STS 
[Snook], which is a high level uascal-like structured 
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orogranmi r.g language. Fecause of the its length, cole is 
located in Appendix C. The code listed in this appendix 
gives the interprocess and intermodule control structure of 
the FSS. 

1 . Shared Segment Interactions 

Supervisor urocess execution occurs in a completely 
asynchronous manner. When a process is refered to in the 
following discussions, the two Host surrogate processes are 
being referenced? these surrogate processes have the same 
clearance levels as the Host they represent. 

As already mentioned, the task of the FSS is to 
provide a service. To he of maximum benefit, this service 
should be unambiguous, easy to use, and robust. 

The major problem that the FSS must handle for 
proper System security is the confinement problem, viz., to 
prevent a process from reading a file with a higher 
classification or writing ;i.e., storing or updating) a file 
with a lower classification. This jcb is handled entirely by 
the Kernel. 

Another problem closely related to the confinement 
problem which also ir.voles the Supervisor, is the 
' readers /vri *e rs ’’ problem [Courtoisl. In order to preserve 
file inte.erety, reading and writing of a shared file cannot 
be allowed at the same time. Since a primary objective of 
the FSS is to provide for the sharing of files, this problem 
will certainly occur and must be handled properly for System 



viability. 

3oth the confinement problem and the reade rs /wri t ers 
problem can be solved in one of two ways. Mutual exclusion, 
a mechar.isf’ 1 which forces a time ordering on the execution of 
critical r°gions, forces concurrent processes into a total 
order execution sequence. This is counterproductive to the 
purpose of a process structure, which inherently allows 
concurrent execution of processes. 

4 second and relatively new method is the use of 



eventcour ts 


and sequencer 


[Seed] 


tc control access 


t 0 


critical 


regions. This 


method preserves 


the idea 


of 


concurrent 


pr A cessing to 


a ruch 


greater 


oy f, Pqt . 


An 


eventcoun t 


is a object 


that keeps 


count of 


the rubber 


of 



events (in the case of the ESS, segment read/write accesses) 
that have occurei so far in the execution of the System 
procedures. Th°se eventcounts are associated with the 
Supervisor segments. They are accessed only via Kernel calls 
and can be thought of as ncn-decreasi ng integer values. Each 
Supervisor segment has two eventcounts associated with it, 
one to keep track of the read accesses and one to keep track 
of the write accesses. 

A Kernel primitive ADVANCE signals the occurrence of 
an evert (read/write segment access) associated with a 
particular segment eventcount. The value of an eventcount is 
the number of s DV. i NCE operations that have been performed or. 
it. A process can observe the value of an eventcount by 
either (READ 'S eg_# , E), which returns the value directly, or 
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by AWAIT ' Seg_# , 17 , t), which returns when the eventcount 
reaches the specific value t, . 

4 sequencer is also necessary to solve the 
confinement and readers/writers problems. Sore 
synchronization problems reauire arbitration (e.g., two 
write accesses to the same segment); eve" tc^un ts alone do 
not have the ability to discriminate between two events that 
happen in an uncontrolled (i.e., concurrent) manner. A 
seouencer, like eventcounts, can be thought of as a 
non-decreas ins integer variable that is initially zero. Each 
Supervisor segment has associated with it. o^e seouencer. The 
only operation on a seouencer is a Kernel primitive 
operation called TICKET • Seg_“ , S), which, when applied to a 
seouencer, returns a ^on-negative integer value. (Similar to 
setting a ticket and waiting to be served at a barber shoo.) 
Two uses of TI CK r T ( Seg_^, S ) will return two different values 
corresponding to the relative ’time’ of call. 

The s egner t number associated with t,h Q se 
synchronization primitives informs the Kernel of which 
segment is being referenced. The use of eventcounts and 
seouencer can be illustrated by examining the following two 
procedures tread <> as not equal). The FSS implements these 
functions in the Direct or y_ Control module located in the EM 



process . 



PROCEDURE reader 
RESTM INTEGER wJ 

abort: w := READ ' Seg_# ,S ) > 'get reader eventcount! 

AW® IT ( S eg_tf , C , w ) ; ! wa i t until write complete! 

” read f ile ’ ; 

if READ ( Sp£_# , S ) <> v; THEN GOTO abortlread again! 

END 



?ROC t ’DUR‘ r writer 
HE5IN INTEGER t» 

ADV®\'CE(Seg tf ,S)J ! increment reader eventcount! 
t TI CKETTSeg_" , T ) > 'get seauencer! 

AWA IT ( Seg_# , C , t ) ; !wait for write tr complete! 
'read and update file’; 

a . DV ®N T v ( S eg_ a , C ) ; ! increment writer eventcount! 

END 



The Kernel will enforce the confinement prooerty and 
prevent the application of the ADVANCE and TICKET primitives 
to segments with an access class less than the Host access 
class. N n t t.c dn so, would allow a communication path to he 
created between two different access levels. The two 
eventccur.ts a Supervisor sermert will have associate^ with 
it (in the Kernel^ are a write eventcount, C, and a read 
eventcount, S. Each segment will also have a seauencer, T, 
associated with it. Eventcounts and seauencer are initially 
zero . 

These eventcounts and seauencers, with their 
associated Kernel primitives, are used hy the ESS to perform 
the synchronization functions of -loch and Wakeup ["Coleman] , 
described in the original Kernel design. Even t courts and 
seauencers provide a clearer picture cf the process 
interaction as well as explicit control of the 
'readers Avri ters ’ problem. Even more importantly, they 
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permit the synchronization between processes of different 
access levels. This is essential in order to permit a high 
level Host to read files of a lower level. 

There are two groups of Host reouests. They can be 
classified as read reouests ' e . g . , 3E*D_EI LE, 'F a D_. a CL) and 
write reouests (e. F o., CREATE_FILE, ST0RE_?ILE). These 
categories can be further subdivided into read data file, 
read directory file and write date file, write directory 
file subcategories . T ach category type must be handled in a 
proper manner by the Supervisor to insure file integrity, 
^ach category will be discussed in turn beginning with the 
read file category. 

There two conditions which might develop over which 
a process has no control; file update by another process, 
ar.d file deletion by another process. a .n example of file 
update might occur while a secre* process is traversing a 
file hierarchy and is ir. the middle of searching the 
directory for a*' Entry_Name when another process (at the 
directory access level) updates the directory. Since the 
secret process will READ th* 3 segment "reader" eveotcour.t, S, 
before and after the search, it will know that the data it 
had obtained is possibly invalid. Although there does not 
appear to be a problem with allowing the ’reading’ process 
to re-read the directory file until a "good" read is 
achieved, a closer examination of this condition should be 
made at implementation time, viz., is it possible for a 
’writing’ process to alter the pathname of a ’reading’ 
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process so that an inconsistent state is achieved for tn° 
reading process? a possible solution could reouire a process 
which suffers a "bad” read to begin the traversal over, 1 
beginning at the root directory. 

When a directory is being read to pass directory 
data back to a Host, the directory data is out in a buffer 
and sent from there. 

? single segment buffer may be to small to hold a 
data file 'e.g., maximum file size of 25?K bytes). 
Therefore, to present the Host with only valid data, a data 
file ''buffer'' is needed at the process level. Since this 
buffer will be at the process access level, it can be locked 
by the process to insure that no other process mterfers 
during the reading ooeration or.ce the data file is ir the 
buffer file. This copying of the data file is done by the ?‘d 
process and the 10 process will read the file from the 
buffer file when transfering the file to a Host system. The 
choice of making a cony of a data file is awkward but 
considered necessary in order to provide the Host with only 
atomic operations, i.e., to prevent the situation from 
occuring where half of a ten segment ms f is transmitted to 
the Host a^d the file is either updated or deleted. 

The other condition which may arise during a file 
read is a file deletion. This situation occurs when one 
orocess is reading a file and another process deletes the 
same file. The first process, not knowing that, the file 
( segment) has been deleted, will try to reference the file 
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again. A hardware segment fault will occur and cause a 
transfer of control to the Kernel. Note that in this 
situation, it is the higher access class process which will 
suffer the fault while it is reading a lower access class 
file. To handle this problem, viz., the Supervisor segment 
fault, a fault handler must be part of the distributed 
Supervisor. A Kernel primitive also reeds defining. This 
primitive, Gatekeeper. On_'Fault ("'’aul t _cor.dit ion , Intry_pt), 
is called in the initialization of the Supervisor process 
where it is possible for a segment fault to occur. A call to 
a Superivsnr condition establisher is also necessary. This 
will place a specific condition handler on a 'condition 
stack". If a fault occurs, the Kernel returns to the 
Supervisor fault handler with a 'segment fault’ error 
condition. This fault handler in turn transfers control to 
the condition handler at the top of the 'condition stack' 
which can make a normal return from all procedures. When the 
error condition is detected (from the return code) by the 
appropriate Supervisor level, action is taken, viz., the 
Host command in re-initiated. Since the file (segment(s)) 
has been deleted, this reinvocation nay well result in a 
'segment net found’ error condition being returned from the 
Kernel and a "file not found" error condition being relayed 
to the Host. When the Supervisor evits the "segment fault" a 
"revert" command is necessary to remove the condition 
handler from t h° condition stack. 

Another side benefit of having the Supervisor do all 
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the actual file reading (and therefore take all the segment 
faults) is that it prevents a hardware fault from occurir.g 
during the actual data transfer in the Kernel during 10 
urocess execution! this condition would force the handling 
of the fault in the Kernel domain — a difficult tasx. 

Writing a file is a more straight foreward task ari 
presents fewer uroblems. This is because a writing process 
has the sane access class as the file and car. prevent all 
other access to the file (segment^)) it is concerned with. 
To alter a directory ( C?.EATP_?IL3, DPL2TE_PIL2. etc.), a 
orocess will get a ticket to the directory and perform the 
necessary manipulation when its number is called. In order 
to store a file, more care must be taken. If a process were 
allowed to store directly into the old file, the possibility 
exists that a software or hardware error might result in a 
partially updated file and loss of file integrity. To 
prevent this from occurring, a data file is first store! 
into a temporary file set up by the PM process. This also 
allows the original file to continue to be read by otner 
processes while the store operation is going on, a 
significant advantage if the data file is long. 5 f t e r the 
file is stored by the 10 process, the PM process gets a 
ticket to the file directory and when its turn comes, makes 
the necessary directory updates, viz., the temporary file 
name is sub si tut ed for the old file Intry_Name, Last_'Jpdate 
information changed, and the old file deleted. (If the file 
is a msf, each segment is, of course, deleted.) 
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2 . 



File M a" axemen t Process 



The FM process is composed of the five modules 
depicted is figure 5 .(with associated Kernel calls). The FM 
orocess is the controller of the F5S and directs all 
interaction between the FSS and a Host system. Each module 
which makes up this process will be described alon,? with the 
procedures which make up th° individual modules. 

a. File Management Command Handler Module 

As depicted in figure 3, the FM_Comnand_Handler 
module see Appendix C, ?. 134) is at the top of the 7M 
process hierarchy. This is the level of abstraction at which 
Host commands are "known". This module is responsible for 
interprocess comm uni ca ti on and synchronization (with the 10 
process) and Host command interpretation. Interprocess 
common icati or is achieved hy the Kernel primitives TICKFT, 
ADVAMC3 and AWAIT which act on ar eventccunt associated with 
the shared nail_box ses^e^t . Figure 9 shows the logical 
construction a^d + h° da‘a base description of the mail_bcx. 
Figure If is a list of the procedures contained within the 
?M_Command_Handler module and their input and output 
parameters. 

The FM_Cnd_Hnd procedure is the entry procedure 
irto the FM_Command_Haniler module. This is the control 
procedure of the module and is responsible for routing Host 
commands tc specific FM_Commard_Handler procedures for 
action. When notified by the 10 process that a command 
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packet is ir. the mail_b"x, th° 7 v i process retrieves the 
command and begins appropriate action. The Tost command 
'e.c., ST0HE_FILF, .-.S a r_FILE) is actually an e^try irto a 
case statement which directs the correct F'^C o mm a nd_ Handler 
procedure to f ake action. Each Host command has associated 
with it, at this level, its own procedure. 

because the procedures of the module are 
relatively straight, forward, they will not be discussed in 
detail. The peroral functions of all the procedures in this 
module are to pass instructions to t^e 10 process and to the 
rirectory_Co i 't T, ol module, the 'workhorse'' of the FM process. 

Some explanation of ' J o5i command parameters is 
i n order, however. These parameters (described below) are: 
pa tr. name 
1 i nk 

file type 
command type 
file size 

0 C C 0 c S lP Tr 0l 

userid 
a n L entry. 

Ir all h^st commands, the pathname passed by the 
Host is the pathname (relative to the ’root' directory of 
the Host virtual file system) of the file of interest, 
whether a directory or data file, ^rom the pathname, the F'd 
process is able to extract the pathname the parent 



directory which it must brins into the F*i process memory to 



checi'- fo r peeper discretionary access. The complete 
Pathname, in terms of the r SS file system, is oassed to the 
Directory_Cortrol module for actual directory mar. i pulati on . 
2 pathname and file size (for the 'buffer file’) is returned 
^dir_pathname, di r_f ile_si ze ) by the Directory_Co^trcl 
module during a ^ost RF 3 D_FILF or STORH^ILE reouest. This 
new pathname and file size is passed to the 10 process where 



the actual data 


transfer takes 


place f 


or these operations. 


Since 


discretionary security 


checks 


are made in the Ft' 


process 


and all 


in put /out put ”b 


uf fe rs ” 


(e.g., temporary data 


file. 


mail bov 


segment) are 


under 


positive Fk process 



control, the 10 orocess need not be concerned with 
ii scre t i cnary security or the possibility of a "segment 
fault ’ . 

A link is a pathname which a Host passes in the 
C?E?TF_LINE command. 

^ile type is used for the CRF 3 TH_FILi Host 
command a n d is necessary because of the different file 
formats. 

Command type is used in the REA.D_?ILE Host 
command to specify the type of 'read' the FSS is to conduct, 
i.e., to read a directory file, a data file, or only a data 
file size . 

File size is passed by the Host during 
S?0?.F_FI LZ recuests. This information is necessary for the 
FM process tc create a temporary file of sufficient size tc 
store a Host file. File size is relayed to the 10 process so 
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that the 10 process can go directly to the lata file without 
having to ch^c^ the directory file for *ile size. File size 
is in tits. 

Access level is needed for th° C?.EATE_FILZ 
command. This allows for upgraded directories (remember, 
data files cannot be upgraded). 

The identification of the Host system user is 
necessary for the FSS to perform discretionary security 
checks. This is provided. by the Host system through the 
userid parameter. 

ACL_” T 'try is used with the add_ 8 CL_3NT?.Y and 
D"L' r TE_A CL_ENTRY commands to give/rescind discretionary 
access f n files. 

b. Directory Control Module 

The Director.y_Cor.trol module, as the name 
implies, does the directory manipulation a.nd maintenance. 
Figure 11 lis + s the procedures which make up this module 
along with their in put /out put parameters. 

Thin is the level of the FM process at which 

files are known. The Direc t ory_C on t o rl module handles tne 
I 

readers/writers problem with the appropriate use of the 
kernel sync ronization primitives HEAD, ADVANCE. A’.vAIT, and 
TICKET. It handles the segmert fault condition by a call to 
the condition establisher when the possibility of a s°gment 
fault exists. The 10 process uses the same primitives while 
performing its portion of the data file read and store 
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operations, viz., the tree traversal wh^n locating the data 
file read buffer or t>e temporary storage file. As 
previously me” ti cued , the IC process will r^t face the 
problem of file deletion while reading and will therefore 
n^t have to establish a condition handler. 

Logically, o s t recnests reauire four basic 
actiors to be peufurmed at this level. They are: 1) to brinr: 
a directory file into process memory for a read and/or write 
ooeration, 2) to delete a file, 3) to create a file, or 4) 
to copy a data file into a data file buffer. a ll other file 
mainte T 'a r ce fu r ’ r 't ic^s suc’ n as mana^ir.-: memory or mana^inrh 
the limited number of segments available :o a process, are 
performed by subordinated modules. There are three 
procedures in this module. 

The Pir_Cntrl Directory procedure is the 
Directory_Conf r^l Tdule procedure which handles Host 
commands wh. i ch reauire tha + the parent directory be brought 
into process memory in order that reauired discretionary 
security checks can be made. These Host commands are: 
EELETE_EILE 
CHE 1 T?_H ILH 
CRE S T T _LI NE 
HEAT_EILE (dir, size) 

F m 1 P _ * tL 
ADD_ ACL_ENTRY 
DELETE 6 CL ENTRY. 



To perform these tasks, 



the parent directory 



segment (which contains the file branch/lin.-c entry) must b° 
brought into rrooess memory to check for trocar 
discretionary access. If access is permitted, the 
Se.emer. t_ Handle r module is called with a pathname of a 
segment reauired to be brought into process memeory. 

For action or. a CrLE?I_IIL£ command, 
discretionary write access to the directory is reauired 
since the bra* ch ^1 ink entry of the file must be removed from 
the dir°ctory when the file is deleted. (Note that this 
raises the possibility of a Host having write access to a 
file but not able to delete it because he does not have 
write access to the directory.) If the parent directory file 
is r.ot found or found but write access to the directory rot 
permitted an appropriate error code is returned, viz., "file 
no r found" "write access not permitted' . 

If an error condition does not arise, the 
directory is brought into process memory and a check of the 
file attributes is made to determine file type (data, 
directory, link). If it is a data file or link entry, it can 
be deleted because it is a terminal node in the fil° 
hierarchy. If it is a directory, the (directory) file itself 
must be brought into process memory to see if the directory 
is empty 'viz., c v sck of Fntry_Count and preserce of a 
Supervisor temporary file). If it is not empty, an error 
code of "not terminal file" is returned to the Host. If the 
directory is empty, it can be deleted. 

If m error condition occurs during the 



to check by the 



preceding ch°cks, the file ^ay ■ subject 
Kernel) be deleted. The Dir_Cr.trl_Directory procedure will 
call on Se 2 _' , r*nd_ M ake_ T Jnaddressatle procedure which will in 
turn call yem_E’id_Swapcut. procedure to remove the segment 
from process memory if it is in memory. (Remember the actual 
order: Swap_Ou*. Terminate, Delete.) Me^t , the Kernel 

primitive, O-ateEeeper .Delete_Segment is called to delete the 
file from the FSS . Mote that in the case of msf's, th c se 
steps must be repeated until all segments of the file are 
deleted. it this time, the branch entry is removed from the 
directory by zeroir.s: all branch entry elements 'to allow for 
Kernel secondary storage compactior of disc pan;es of zeros). 
The 10 process is then instructed to acknowledge the Rost 
with file dele* ed . This f’-ees the entry for future use. 

T^e deletion of a link reauires the same 
discretionary writ 0 access to the directory. I 1 "’ this case, 
.no further checks a re necessary and the link entry elements 
are zeroed in the directory, freeing the entry for re-use. 

T or the ''HE ! TF_ r I command, analogous action is 

taken by the Dir_Cr.trl_Di T *ectory procedure, viz., to check 
discretionary write access to the directory which will 
contain the file branch entry. 

Once this check has been satisfactorily 
completed, a’-d ro n n p vists in the directory, the Kernel call 
Oatekeeper . Create_Sesment is made to create the file. The 
initial file si?° is zero for data files since the 
Supervisor has no prior knowledge of the size of the file 
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that will be stored in the branch entry. As explained 
earlier, a file size of LARDE (8K bytes) was selected for 
the fixed directory size. 

The CEEATE_LINE request is again analogous, the 
only difference being that instead of a branch entry being 
made in the directory, a link: entry is made. As previously 
mentioned, the Supervisor will not allow a loop state. 
Checks will ** t be nade at. link creation tine! however , the 
Supervisor will ’abort' a file search if it encounters this 
error conditio’ 1 du~i n g tre° traversal. 

The Mir) command reouires read access 
t r a directory file. If *>o error condition arises during 
discretionary security checks, selected directory data 
'e.g., 5ntry_Mame, ?ile_Size, etc.) is transfered to the 
Host system via t^e mail_box segment (viz., 
Dir_Eata_Buf fer ) . This selected directory lata for each, 
’occupied" branch/lirk entry is transfered during the 
RZAB_?ILE dir) command. Tor the READ_ZILE (size) recuest, 
only selected directory data for a specific -data file is 
transfered. The 10 and EM orocesses use appropriate Kernel 
synchronization primitives to assure that the information in 
the mail_tcx segment is valid. 

The last thr<=e Host reouests handled by the 
Dir_Cntrl_Direct ory procedure are related. Again, 
appropriate discretionary access checks must be made in the 
parent directory. If no error condition arises, the action 
taken is straight foreward. In the case of the HE'D ACL 
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command , 


the file 
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the proedure r 


e t u r r s 
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F v Command 
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case 


of 
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s DD(DELFTi;'_. fi CL_EMTRY commands, the action is completed ’ey 
the Dir_Cntrl_Lirectory procedure and the appropriate 
Di r_Succ_C ode returned. 

The T 'i i '_Cr. trl_Cata procedure is responsible for 
trarsfering tn a Host a reouested data file if 
necessary nrecond it tors are met (viz., discretionary and 
ron-discret i or. a^y security). In order to read c ^ s^cre a 
f ile , a Host must have the pr oDe r discretionary acces s to 
the file. To check this, the parent directory which contains 
the file branch entry •rust he brouefct into memory. This is 
done by the Ser^e^t _Handler module. If the proper access is 
rot allowed, an error code is returned to the 
HM_Comnar.d_Eardler module for relay to the Host system. If 
the proper access is allowed, a copy of the file is made in 
the case the HF“D_?ILE command, or a temporary file is 
created in the case of the STCRT_ V ILE command. The pathname 
ard file size of the data ^iles to be transfered are passed 
to the 10 process which will perform the actual data 
transfer. Upon a successful transmission of the data by the 
10 process, the 1?v orocess instructs the 10 process to 
acknowledge the Host with a "read complete" cr "store 
complete’, as aporooria te . 

The Ei r_Cnt rl_Data procedure will make 



appropriate use of kernel synchronization primitives (e.g.. 



AW a IT , R^AD, etc.) when copying a data file into the data 
file read buffer or setting up a temporary file for the 
store operation, after the file transfer has taker, place ir. 
the 10 process, the IC proc°ss returns a success code tc the 
Tf* process. The 10 process will return to the process 

v/h e r one of three conditions e T ist: 1) either the read or 

store operation is successful and complete, or 2 ) a command 
packet is ’"ecei’ ,D '’ (viz., an abort command), cr 3) a 
’time-cut’ occurs and the 10 process was not able to 
complete the command . 

7 or a store operation, the Dir_Cr. t rl _Upd ate 
procedure is ''ailed to update the directory data (viz., 
exchange the temporary file ? r.try_ N lame with the old file 
2ntry_Nare) a^d deletes the old file, fine temporary file 
should be deleted by this procedure if, upon attempting to 
update the file, the old file cannot be found.) 

Since each directory segment has only one 

temporary file for file update, so^e delay may be 

experienced by ^ost systems if several try to store large 
files irto th a same directory. This does i-ot appear tc be a 
major problem since most, users are anticipated to be 
operating from their own directory files. 

The hir_f^nt rl_Upda te procedure is also used to 
free the temporary storage file in the case cf a Host abort 
command . 

c. Discretionary Security Module 
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The Tisc T *etior.ary_Secur ity module is resuonsille 
for checking Host user discretionary access to a specific 
file and addins and deleting ACL_entries . All file a CL's are 
logically located in this -nodule. This is the only other 
module besides the Tirectory_Co ri trol module where a segment 
fault night nocn’. Appropriate us° cf the condition 
estahlisher must he made before any attempt to read an ACL 
so that a proppr return is °r ecu ted to the Di rector y_ Cor. trol 
module in the event of a fault. There are four procedures 
which make up this nodule as depicted in figure 12. 

The Li sc _Se c_Chec k:_ 5 c ce s s procedure, as the name 
implies, checks f n r a specific us°r discretionary access to 
a specific file. a success code returns, indicating the 
result of the check. This discretionary check is only made 
on the specific file which is recn:ired in a Host command, 
i.e., a design choice was made not to make discretionary 
access che cks during the tree traversal search for the 
specified file. This makes explicit in one ACL who has 
access to a file, which contributes to clear security 
semantics. (This also eliminated the Question of what to do 
if an intermediate directory was encountered during a file 
search to which the process did not have read access.) 

The THsr_Ser_ a dd_. ! CL_Znt ry procedure adds an 
ACL_entry to a file ACL and returns a success cole to 
indicate the action taker.. a s noted previously, a directory 
has a limited number of ACL_entry elements. The Supervisor 
only guarantees ore a CL_entry element per branch entry (for 
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the file creator). If another ACL_entry is reouired and tne 
! \CL_eri try "oool" is empty, an ACL_ertry element will have to 
he explicitly freed from a file ty the Host before a file 
4 CL car; he added to. 

The r 'i sc_Sec_ r >elete_. 4 . r L_Tnt ry procedure performs 
the straight foreward task c f deleting an - CL_e.o t rv from a 
file ACL. This procinre returns a success code when deletion 
is complete . 

The last procedure of this module is the 
Di s c_S ec_de t _£ CL pmcedur 0 . It is used during the ir.tiel 
creation of a file ty the Tirect ory_' , ontrol nodule to get an 
initial ACL_E n try ®l o, Tent. 

4. Segment "Tandler Module 

The 3egmer.t_Ear.dler module is the abstraction 
level at which Supervisor segments are known. This module 
works i r. conjunction with the fferro T \y_Har.dler module 
'described later) to either bring a segment into process 
memory (v i?., Make S’*'ap_Ir) or to terminate a segment 
(viz., Svap_0ut, Terminate). This module is responsible for 
maintaining the FINEST (known segment table — figur° 13) data 
base. The data base elements of the ^M_KST are the pathname 
of a segment known 1° the process, the segment number 
(Seg_£) of the terminal file in this pathname, mode (i.e., 
reed or write), a^d the use bit necessary fcr a LL’J removal 
algorithm ( apuroximati on ) . To prevent the situation where a 
segmen t has le°" deleted by or.e process but is still 
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ir.iicatei as "in memory" by another process, each new Host 
command will initiate a kernel call. Gatekeeper . Swa?_In 
Base_ £ ddr), to confirm the existence of a segment. /• 
Hernel return o^ "segment not found” will indicate that the 
segment has been deleted. The ^SS must then clear its data 
structures invalid data and traverse the virtual 

hierarchy from the root directory to insure that the segment 
is truely gone and that it has not been renamed by another 
process i.e., + o cover the unlikely situation where a 
pathname has b°en deleted and then re-created with the same 
filenames. This would associate different segment numbers 
with the same cathname. 

Tipurp 14 is a list of the ?rocdur Q s of this 
module along with their input/output parameters. This module 
receives a file segment pathname and returns when it has 
been brought into process memory or an error condition 
arises. The possible er^or condition that might he returned 
from this module is ’file rot found'. This module has two 
tasks, ard the T ‘ p fore two procedures. To make a segment 
addressable by the -ost process (viz., bring it into process 
memory) or to make a segment unaddres sable by a Host process 
(viz., to remove the segment from process memory). The 
procedures which handle these tasks are the 
S e g_H nd _ Mak e_Addressahle (i.e., bring a segment into process 
memory) and Seg_Hrd_Make_Un.addres sable (i.e., remove a 
segment from process memory) procedures. (Mote that to maxe 
a segment addressable also recr’ires making the segm en t 
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'known ’ and that making a segment unaiiressahle reauires 
"terminating" th° ser^e^t.) Both tasks are accomplished by 
appropriate use of kernel primitives and accompanied by 
calls to the f / !e m ory_Kar il er module to 3wap_In or Swap_0ut a 
segment . 

This nodule is also r°sponsible for segment 
management. Segment management is necessary because each W MU 
allows the add^essi”,? of only 64 semen t s . With one MMU ir 
the initial ^SS implementation and several segments taken by 
the Supervisor ar^ Kerne] segments, the number available to 
the Supervisor processes will be somewhat less 
( M a .X_KM0Vi N_SIG ) than 64. This number must be managed in a 
dynamic manner without interfering with process execution. 

The Seg_Hnd_fdak Q _Add res sable procedure is the 
more involved of the two module procedures. If a reouest to 
make a segmprt, known is reosived , the 7M_K3T is checked to 
see if it is already known. If it is, the LRU hit is set and 
the Memcry_Eard ler module is called to assure that the 
segment is in orocess memory. If it is not already gn own to 
the process, it. must he made known ’ov the Kernel call, 
Gatekeeper .^ake__Known (Par_seg_ :! t, e nt ry_# , mode). But this 
can only he done if process segment limit is not exceeded. 
If the addition of a segment will cause an overflow, a 
seg~er + must he removed by the 3eg_Hnd_b'ade_ 7 Jnaddressable 
procedure. Once this is done, the desired - segment can he 
made known, the TT_KST updated, and the Memo ry_Kand ler 
module called to bring it into process memory. 
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procedure 



The Sag_Hnd_Make_Unaddressable procedure is 
straight foreward. This procedure may be called to either 
delete a specific segment or to delete the LRU segment. If 
called to ~emove a specific segment, actior is taken to 
remove the segment (described below). If called to remove 
the LrU segment, a LPU removal algorithm ''approximation) is 



used to determine which segment will be remove* '//hen this 
has been done, the Memo’*.y_* J andler module is called to 
Swap_Cut the segment from process memory. A returned success 
code ird i cates that the segment has been removed by the 
Kernel call Gatekeeper . Swap_Cut (3 ° A call is then made 
to ternirate the selected segment. The Kernel call, 
Ga tekeeper . Termi oa t.e f ?ar_ Spg_~, Tntry_K^), will cause *he 



segment to be deleted f’os the Kernel E5T. Removing the 
segment pathname ^rom the ?/_KST will complete the action 
taken by this procedure. 



e . i' , 'e rT ’OT>y Han* ler Module 
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'.vher the Mem_Hnd_Swap_I r. procedure is called, 
the PM AST, figure If, (active segment table) is checked to 
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see if it is already in memory. If it is, its LAU bit is set 
and C-a t ekeepe r . Swap_In f Se.g _# . 7ase_ a ddr) is called to 
insure that the spgmert has not, been deleted by another 
process since last use. If the segment is not in memory, tr.e 
!“!TM_MA? data structure, figure 17, is checked to find room 
for a segment of the reauired size. Arguemerts car be made 
for both a first-fit and best. -fit. memory management scheme 
[Shaw]. 1 first-fit scheme is chosen for the K3S due to the 
simpler implpmera t i on and *he reduced memory fragmentation. 
If room cannot be found, ‘- 1 em_ t lnd _Swap_0nt is called 
iterativelv u " t 1 1 enough room exist for the segment to be 
brought into process memory. a Kernel call, 
Ga t ekeeper . Swa pi ” (Seg_“, 3ase_Addr), is used tc mo ve the 
segment into process memory when room exists. 

Mem_End_Swap_Cut may either be called to remove 
a specific segment or to remove the 1 U segment from proc°ss 
memory. If the reouest is to remove a specific segment, the 
task is straight foreward; a call is made to the Kernel 
primitive Gatekeeper .Swa p_Cut (Seg_*). If the reouest is to 
remove a specific segment, a LRU algorithm (approximation) 
is used tc det.ermire which segrent to remove. When this is 
done the Kernel call is made and the Memory_Ear dler data 
bases are updated to reflect the segment, removal. 

*- preliminary analysis of memory reauirements 
indicates that process lirear virtual memory will ^eed to be 
at least ?.\T. bytes. The driving factor in this calculation 
is the fact that two data segments (possibly SK bytes each) 
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may be reauirei in process memory during the copying cf a 
data file, into the data file "buffer". A 24?'. byte memory 
would allow for the worst ^ase, viz., or.e SX byte segment 
positioned in th° middle of linear memory? room would still 
ezist for the two 9X byte segments. 

3 . Input/Outout Process 

The TO rrocess is the second of the two processes 
which act or behalf of a H^st system to provide a reoues + ed 
file management service. The 10 rrocess acts in a slave mode 
to the Ft' process? i * receives i + s commands from the F k 
process via the shared mail_hox segment described in 
connection with the "k process. 

The 10 process is responsible, as the name implies, 
for all input and out on t between the Supervisor and the Host 
systems. The 10 process is "opposed of five modules as 
depicted in figure IS (along with Kernel calls). Two of 
these modules, Segment_~andler and Memory_Handler , are the 
same modules as ^“scribed ir th° Fk process and will rot b° 
discussed further. Their task is to bring into the virtual 
memory cf the IC p^oces^ the data segments into and from 
which "ost files are stored or read. Note that since 
discretionary security checks are dene ir. the Fk. process, 
the 10 process does not have to repeat these checks. 

Direct invocation of the ?acket_Eard ler "c^uIp from 
the I C_Comma nd_- T and ler module is Possible to send Host 
"acknowledgements” . If a file is to be read or stored, the 
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File._Handler module is first called to perform the read or 
store operation. 

The 10 process is also responsible for FSS-Host 
Drotoccl. Fata is transfered between Host and 7SS via fixed 
size "packets". There are thr°e formats for these pacxets: 
1) a synchronization packet format, 2) a commani packet 
format ard , 5 ' a data packet format. Figure 19 gives the 
logical construction of the data and command packets. The 
synchronization pa eke* is left for later design in 

connection with the design for a Host interface. The packet 
size of 521 bvt p s for data ark command packets was chosen to 
maximize data transfer efficiency at the excense of 

increasing the romr-’a”'d packet size. Because 512 bytes is the 
size of the smallest Supervisor segment, this was chosen as 
the "u’nt" of data transfer. 

5 protocol must p xist that insures reliable 

transmission and T,p cept ior packets by both the sender a^d 
receiver in the FSS-Host packet exchange. The simplest 
protocol that, will handle packet transmission is to transmit 
packets one at a time and wait for packet a ckn owledgemen t 
before sending the next packet. The following diagram 
illustrates this simple nrotocol. 

Pacxet 'n) --> li^-p 

<— 4 ck 

Packet — > 






nar» packet 
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Operating ir this fashion is extremely inefficient, 
especially in the transmission cf large data files! it does 
not allow the sender to send oackets before an 
acknowledgement is received nor does it allow the receiver 
accept more that one packet at a time (i.e., read ah°ad 
and write behind). A multi-packet protocol is necessary to 
take advantage of a read ahead and write behind scheme. 

In specif ing a mul t i -pa cxe t protocol, some means of 
distinguishing individual packets must be established. This 
is done by giving each packet a seauence number carried in 
the packet header. The receiver returns acknowledgements 
indicating the sequence number of the packet ( s ) received and 
accepted (i.e., no errors detected). The number of packets 
that may be transmitted before an acknowledgement is 
received is called the packet "window width". Packet 
transmission is controlled by an algorithm which uses packet 
seauence numbers and the window width. At System 
initialization time and anytime a c ommar.d packet is 
received, the seauence number of the FSS is reset to zero. 
Thus the first seauence number expected by the 735 upon 
system initiation fand afterwards upon command completion) 
is zero. 



7 or an explanation of how the packet window works. 
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the FSS , the Host is allowed to transmit packets bearing 
s p auer.ce numbers in the ran.ee . The rereiver expects 
the. packets to arrive i" correct s^ouertial order. As they 
arrive, packets are checked for correctness 'at both the 
hardware (3SART) and software level); an incorrect packet is 
discarded and ^ay be considered ’lost*. Let the secuenre 
number of a particular correctly received packet be S. If 
3=N(t-l) (i.e., the expected packet), then the packet is 
received in the correct s^cuerce an i it should be accepted 
by the receiver and ar acknowledgement sent with the pnopen 
secuence number (in this case, S) to the sender. If 
S'N ( t*l) , then the packet is a repetition of a packet 
previously received by the receiver*, the second transmission 
may be due to either a lost or delayed acknowledgement. The 
receiver should generate another acknowledgement and send it 
to the sender and otherwise ignore the packet. If 5 ( t ->-1 ) , 
then the packet is ah^a^ of secuence, indicating that an 
earily packet has bee*" lost; such a packet, should be ignored 
and an "error” acknowledgement sent so the packet can be 
retransmitted . 

The arrival of acknowledgements at the sender also 
ne°ds to be discussed. As each acknowledgement arrives, the 
sender can delete the copy it has retained of the 
corresponding packet. As packets are acknowledged, fresh 
paokets cs.r be transmitted, i.e., when packet ?, has been 
acknowledged, packet V can be sent. Acknowledgements can get 
lost in transmission as well as packets. If a received 



acknowledgement does not refer to the earliest transmitted 
packet awe i t i n g a^kn ovied gemer t , them, in this protocol, the 
sender may safely delete all packets up to and including 
that ~ef er ori ced hy the acknowledgement. Against each copy of 
a transmitted packet will he noted a time (i.e., the 
time-out) hy which time the packet must be acknowledged. 
Failing such an acknowledgement, the packet must be 
re t ra "smi 1 1 ed with its original seauence number. A packet 
will only be received in sequential order, so it will be 
necessary to re^ra^smit not only the earliest unacknowledged 
oacket , but also all later packets. The following figure 
illustrates this protocol. Th° queues should be considered 
as circular with automatic wrap-around. 




In this figure, the sender is node A and the 
receiver is node 5 . Mode A has sent out packets 3,4, and 5 , 
the last of which is still in transit to 3. Node 3 has 
received all packets up to and including 4. It has just 
acknowledged 3 and 4 and is ready to accept 5,6, and 7 when 
they arrive in order. When node A receives acknowledgement 
f o r 3 and 4. it will be able to transmit successfully 
packets 5 and 7. 

This protocol insures that packets are handled in 
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seauential order which will insure that the data is receive! 



and stored correctly. It also assures positive control over 
the receipt and transmission of packets ? a necessary 
requirement to prevent, buffer overflow and loss of data. 

The r emel controls all the hardware assets, as 
explained in Chapter l. Kernel calls are therefore necessary 
to transfer packets between the FSS and the Host systems. 
The format of these kernel rails are: 

Cat ekeeper .Setup (^uf f _Addr , Mode, Status ) 

Gatekeeper .Send_?acket '’Offset, Status) 

Gatekeeper .S tore_?acket (Offset, Status) 

Gatekeeper . Char.?e_Byt e_C our. ter f #_of_3ytes , Status ) 

Fa ch hardware port is virtualized into a” input and 
an output port. Fach virtual port has associated with it a 
unit control block (UC3) at the Kernel level. The elements 
of these U C 3 ' s ar^: 

3yt e__C ou n t er : This element is used to keen track of 
the number of bytes that have been transmitted or received. 
This counter is modulo "packet size" so that once packets 
are synchronized, they should remain so. It can be altered 
by the Chanpe_Syte_Counter call in order to get the FSS and 
*ost. back into racket synchronizati on . 

3uf f er_Aid ress : This is the starting address ir. the 
input/out buffer where rackets will be placed (ircommins) or 
taken from (outgoing). It is initialized by th^ Setup Kernel 
call . 
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T uf f er_Lenet h : This element is the length (in 
packets'} of the i*' put /out put buffer. This allows the Kernel 
to perform automatic wrap around at the end of the buffer. 

V/irdow_Width : This element is used by the incut port 
UC3 to prevent buffer over flow. Each invocation of 
5tore_?acket will advance the window and allow another 
packet to be stored into the 10 buffer. If a Host system 
violates protocol by sending too many packets, the Kernel 
will dump them to a "bit bucket". This element is used by 
the output port to control the number of packets that the 
ESS is able to send to a Host before receiving an 
acknowledgement. sitfcou<?h this parameter (viz., window 
width) may be different for the various Host systems, it 
should rot change often and car therefore be set at system 
initialization. 

Eo" a s t ore operation (F35 to receive packets), a 
Setup call is used to set the input UCB base address to the 
initial storage location in the 10 buffer. A Setup call is 
also reauired to set the output UCB with the base address in 
the IC buffer from which acknowledgments will be sent. It 
should be noted here that the 10 buffer in the 10 process is 
the location that packets are checked for errors and 
’enpacketed" or "d epacketed " . It is just a intermdiate stop 
for data and neither the final destination nor origin of 
da ta . 

Subseouent Kerrel calls to Store_?acket will returr 
the location of the next packet in the 10 buffer to be 
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processed. The Kernel will store ahead into the 10 buffer 
during the store operation but will not over write the 
buffer. That is, each call to f he Kernel will indicate that 
a new packet location is omen. The 10 process will control 
which packets (and how ma^y) are sent to the FSS by proper 
use of acknowledgements 'for both correct and incorrect 
packets } . 

Two Setup calls are also necessary for a send 
operation. They again set the virtual input/output ports for 
the transfer of packets from the FSS to a Host. Subseauent 
calls to Send_Pa cket indicate that a Packet is ready to be 
transmitted. The 10 process knows whe" it can discard a 
packet by the acknowledgments it receives from the Host 
s y c t sr 

The f’hange_' c yte_C oun ter primitive is used by tr.e 
sy ri chron i za t i on procedure to shift a UC3 byte counter in 
order to bring packet transmission back into 
synchronization. (Synchronisation may be reouired during a 
temporary communication interruption or system start up.) 

The following is a description of the three "new” 
nodules which make uo the 10 process. 

a. I^uut/Output Command Handler Module 

At the top of the 10 process module hierarchy is 
the I0_C ommand _Hand ler module ^see Appendir C, p. 117). This 
module is responsible for the interface with the PM orocess. 
Communication between the processes is via the mail_bor 

oo 
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shared segment ard synchronization is through the use of ar. 
even tc our t, and the Kernel primitives TICKET, J D7 ANCF a^d 
WAIT. The urocedu res of this nodule alon^ with their 
input /on + put parameters arp listed ir. figur® 20. 

The IO_ r 'nd_ I Ini procedure, like the ?M_Cmd_ u ni 
procedure a ca = ® statemert, routes EM process instructions 
to a specific TO_ r 'ommand_"andler procedure for action. 

The procedure involved when the Host command is 
not a RTiD^IL" or STOR' T _' T TL' :: ' reauest is the IO_Cmi_Hnd_Ack 
procedure. This procedur® is able t® invoke the 
D a eke t _Hand 1 er nodule directly for performing directed (by 
the FM process) Hos + acknowledgement and/or data transfer 
from the shared mail_bcx segment. 

The IO_Cmd_H r 'd _S®ni and IC_Cmd_Hnd_Store 
procedures are relatively straight forward. They provide the 
IC-FM process interface reouired for a. r. I A D _ F I L F or 
3TORF_FI LF TJ ost reauest. Roth procedures call the 
File_Hardler nodule to perform the actual file n-ani pulaticr. . 

b. File T - T andler Module 

The File_Handler module is required for file 
manipulation in the IC process and is the level in tne 10 
process at which files are k^ow®. The procedures which make 
up this module alon^ with their input/output parameters are 
listed in fignr® 21. As mentioned above, there are only two 
Host requests that reouire the 10 process to bring data 
files into process memory. These are RFAD_FILZ and 
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ST0H7_ r TLT. Note that since file size is passed from the Fh 
nrocess, and the *he access to the data files involved is 
controlled in the nrocess, data file segments can he 
brought directly into 10 process memory and any r a auirement 
for the IC process to access directory files (other than 
tree traversal) is eliminated. Because the terminal nodes in 
the tree traversal are controlled by the F M nrocess, the 
paths to these terminal "odes will not he alterable until 
control is released by the 11 M process. 

The Fi le_Hand ler module consist of two 
procedures, 7i le_ tr nd _Send_' p i le (for Host conmand RFAD_FILE) 
and Fi le_H , 'd _S + o n°_Fi le Host command STORE_FILE) . Both 
procedures operate in a similar manner. Upon receiving a 
pathname a^d file sine *“rom the FM process, these procedures 
use the Segment_' J aniler procedures to bring the necessary 
data file (segment(s)) into pnocess memory. A call is then 
made to the Pa c^et_ T7 andler module to transfer data from/to 
specified segments. 

The order of events in the reading and storing 
of data files follows the following sequences. For a 
RFAI^FIL 7 operation. the order of actions tak:en by the 
Supervisor are: 

1) discretionary and non-di scretionary checks 
are made in the FM process. 

2) A copy is made of the data file into a 
per-process data file buffer. 

•H) The math name of the data file to be read 



92 



(reme, Tiber, directory data is read by the FM process) is 
passed to the 10 process along with the file size. The 10 
process car d ot ’er r ri r, e the file sice from the file directory 
tut by passing f ile size to the 10 process, this step is 
eliminated fo»* thp 10 process. 

4) The read takes place in the 10 process. 

5^ The 10 process returns to the FM process with 
a success code of ’’read complete" or an appropriate error 
code. The or ly reason for a read operation to fail in the 10 
process is the receipt of an abort command from the Host or 
a ’time out’ which would occur if the Host stooped sending 
for some unexplained reason. 

6) Th p FM process irstructs the 10 process to 
acknowledge the "read complete" or to send the appropriate 
error code. The data file read buffer is then free for 
further use. 

I f th° operation is a ST0R3_FILF operation the 
following steps are taken by the Supervisor: 

1) Discretionary and non-d i screti onary security 
checks are made by the FM process. 

?.) A temporary file is created by the Supervisor 
large enough to store the file in. “poropriate use of the 
synchronization primitives prevents this temporary file from 
being used by more than one process at a time. 

3) The pathname of the temporary file is sent to 
the 10 process and t v e 10 process stores the file into the 
temporary file. 
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4) The 10 process returns a success code tc the 
^M process and the ^M process updates the directory to 
reflect the new file (viz., Entry_Name of temporary file is 
changed to the old file T n try_Name ) . The old file is then 
deleted hy the EM process. 

5) The EM rrocess then instructs the 10 process 
to acknowledge the "store complete". There is no reason a 
store operation should fail other than an explicit abort 
reauest by the Host system or hardware failure. 

c. Packet Handler Module 

The Packet _Hand ler module does the actual 
transfer of data between the ^SS and the Host system and is 
the 10 process le^el at which the concept of "packet" is 
known. The procedures of this module alons with their 
input 'output parameters are listed in figure 22. The tasks 
that this module must oerform are: 1) synchronization of 
packets, 2) e^-r^r detection, 2 ) packet acknowledgement, and 
4) transfer of data to/from {Supervisor segments. Eigure 23 
is a finite state diagram of packet transfer. 

The synchronization task is performed on the 
svstem IPL and whenever packet synchronization is lost 
thereafter. Error detection and reauest for retransmission 
upon, error detection are compl ime^t ory functions which a^e 
performed on every packet received from a Host. 

Packet. transfer during synchronization 
procedures is in ?rours of three. This allows the 
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■> r i;?u~e 23. finite State Pia^rram of Packet Transfer 
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synchronization procedure to berir. synchronization in the 
middle of the first packet and still have two rackets to 
confirm synchronization when it is achieved. 

Packet transfer of command packets occurs one at 
a time. The reason for this is that each command packet must 
be acted unon in a synchronous manner. Data packet read 
ahead and write behind is permitted to increase the transfer 
rate of data packets. The number of packets that are allowed 
to be sent or stored depends on the IC buffer size. The 
?acket_Handler module is also responsible for data 
"enpacketing" and "depacketing” for the FSS. 

The ?k_Hnd_Synr procedure is used to synchronize 
packet transmission. It is explicitly called at I?L and 
wherever the packet synchronization is lost by the Host 
system. It is invoked implicitly by the FSS whenever a 
packet is not able to be decoded 'viz., the packet type and 
packet check-sum are incorrect). 

The ?k_End_Ack procedure is used to send 
acknowledgements to the n ost systems. This procedure will 
always be called f^om the IO_Command_Handler module which 
will require the ?acket_Eandler module to either acknowledge 
the Eost with a specific message or to send some data 
located in a mail_box segment buffer to the Host. 

The Pk_End_3en.d procedure is used to transfer 
data segments from the FSS to a Eost system. This procedure 
is called from the File_Handler module which makes sure that 
the correct data segment is in process memory for the 



97 



I 



trarsfer The segment number along with the number of bits 
that are reauired to be transferee! are passed to this 
procedure from the File_Handler module. This procedure then 
transfers the segment until the specified number of bits 
have been transmitted. A success code is returned when 
action is complete. 

The ?k_ tr nd_S tore procedure works in a manner 
completely analogous to the ?k_Hnd_Eead procedure. 
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III. CONCLUSIONS 



A. STATUS 0? R^S^RC? 

This design applies state of the art software and 
hardware to solve the secure multilevel computer problem in 
a file storage system. It. presents an inexpensive but highly 
uowerful design for a system based on a micro-computer tut 
not, restricted to a micro-computer environment, i.e., there 
is r.o restictior on the type of Host computer system 
serviced bv the ?SS . Implementation of this des ign on ZS!?0? 
hardware along with the analysis of ?SS design parameters 
(Appendix A) are tas’-rs left to be done. 

There ar° two ma por classes of applications for the FSS . 
Cr.e application, uses the ?SS as a system file system (e.g., 
for distributed micros'. This implies that the total system 
is multilevel secure with n rly one secur° component (vie., 
the Kernel). It must be noted, however, that in this 
configuration, the distributed Hosts (i.e., the micros) have 
no autonomous life. 

The other class of appl ica ti ons . involves using the HSS 
as one element of a net of autonomous Host systems. In this 
configuration, the 7SS provides facilities foo controlled 
data sharing and communication. 

An obvious direct application of the HSS, is for 
shipboard use (e.g., for the SNAP-II system [Smith]) or for 
use at other installations where data would be more 
efficiently used if controlled data sharing were allowed. 

cc 



3 major design choice of the 753 which allowed the 
Kernel to he kept small 'and therefore more easily 
verifiable', was the elimination of the discretionary 
security from the kernel domain to the Supervisor domain. 
The implication of this choice is that each Host system is 
responsible for its own discretionary security? not an 
unreasonable T 'ecuest or design choice. 

The next major task to he accomplished in this project 
is 7SS imolemp’' t at i on . This will not he a trival task, hut 
it is felt that the designs Dresented in this thesis and tne 
companion work dene by Col°nan provide a solid basis. 



7. "FOLLOW ON WORK 



This desi? r i <= a specific implementation of 
of a family cf operatir -2 systems based on 
Kernel co”' r ep + discussed by 0 , Con. r. ell and 

[0 onr.ell] . There are obvious areas that this 
be expan ^ed ard generalized; areas that should, 
after a successful first implementation. Some of 



one member 
the S e c u r i t y 

2 i cha rd so^ 

design could 

00 ov’^rr’^'r'pr^ 

t h 5 S 9 a f 6 d 5 



are : 



’operator’ terminal interface funcior.s 
expanded Host commands 

map of >t different ’user’ names in different Hosts to a 
common "user” in the r SS 

data c^npa c* in^ onto secondary storage 

multilevel 3 o s t s 



moving discretionary security irto the Kernel domain 



dynamic process creation ''deletior. 

These are just- a few of the many possible areas for 
e^parsic^ that cnuli be e^pl^rei. 0 r e area not mentioned in 
the list but an area that should be looked at during the 
initial i rrpl empr- ta t i c n is for a way to prevent the 
Supervisor from suffering a 'segment fault’. The present 
arrangement , with a faul + handler, is not efficient or 
'elegant'. Since the deletion of a segment is controlled by 
the relete_Segvi="t; Kernel primitive, a method of leaving an 
'orphan' cony in process memory would eliminate the fault 
condition. The o^ly operation that would be defined on this 
’orphan' would be a Pelete_Segmen t command by a process to 
remove it from process memory. After it had been deleted by 
all processes, the cony could be destroyed. A variation of 
this scheme would, upon a Kernel Swap_Ir. call, swap into 
process memory a pe^-process copy of the desired segment. 
Sw'ap_Cut would b° used to o ree process memory. 
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i ?pTi\|T) j j a — SYSTEM ? a .R ? MET ZRS 



S^ALL 


Sogrre^t size 


512 bytes 


MEDIUM 


Segment size 


2 X bytes 


LARGE 


S pg^er. + s i 7,® 


SX bytes 


M. 6 X_EILE_SI 


M ax file size 


25FX bytes 


MAX_EMTEY 


May ^ i r entries 


32 


ACL_POOL 


M ai * cl Entries 
per ii rec t o ry 


13?4 


Pat hie ’13 th 


Max 


12 ? bvtps 


Ertry_Mane 


Size 


1 ? bytes 


S” own Segments 


Ma^ per process 


— 
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APPENDIX 1--SJCCESS AND S-.ROA CODES 



CODE 


LOCATION 


p ile Deleted 
File Created 
link_C re a ted 
St ore_Cc'T’ple te 
?:ead_Co'nplete 
4 CL_Reed_Compl et e 
ACL_Er try_Added 
1 CL_Entry_Dele ted 
Cmd_.A tor ted 
Cmd Packet Expected 
Ille?al_Cmd 
11 legal _Cmi_ r o mat 


FM_Cormand_Haaller 
Mod ul e 


File_Mnt_ Fon r i 
\ ! o t_ Tern inal _ 1 *’ilP 


Direct my Control 
Module 


Vri te_Acces s_N ot_Allowed 
-ead Acc es? _Mo t_A 1 lowed 


Li scret ioaary_3ecuri ty 
Module 


Time_Out 
Mo_Sy r i c 
?acket_Ack 
Packet r rror 


Packet_Handler 

Module 
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APPENDIX C 



EM COMMAND HANDLER MODULE 



CONSTANT 
FALSE := 0 
TRUE := 1 
NULL := 0 

EXTERNAL 

DIR CN'TBL DIRECTORY PROCEDURE 'MSG BYTE 

USERID BYTE 

PATHNAME STRING 

FILE TYPE BYTE 

*C CESS*1~VE1 BYTE 
LINS STRING 

A CL_ENT?.Y A CL_TY?E) 

RETURNS '■ DIR_SUCC_CODE - YTE ) 

’for host ends that require parent directory: 
delete_f i le . 
create_file, 
creat,e_li’- | h , 
read_acl , 
add_acl_ent ry , 
delete acl ert^y! 



DIR CNTRL DATA PFOCEDITE ( MSG BYTE 

USERID ^YTE 

PATHNAME STRING) 

?ILE_S IZE LWORD ) 

RETURNS ( DIR_SUCC_C0D T ’ ^YTE 

BIR"PATENAME STRING) 

!for host c-nds that access data file: 
read_f i le . 
store_f ile ! 

DIF._C NTRL UPDATE PROCEDURE 'MSG BYTE 

USERID BYTE 

PATHNAME STRING) 

RETURNS (DIP SUCC CODE BYTE) 



1 1 o update directory after io orocess 
acts or host c™ds: read_file, store_file, 
abort ! 



GLOBAL Jmoiule entry point! 



?M_CMD_HND PROCEDURE 'case statement on Host cmis ! 

ENTRY 

DO 

M»IL_?0X. MSG. INST := PF a D_CMD 
MAIL_30X. MSG. PATHNAME := NULL 
MAIL_30X.MSG .FILE_SIZZ := NULL 
M AIL_R0X. M SG . SU rr, _ r OD 7 := NULL 
t := GATE •CEE PER .TICKET (MAIL_30X, C) 

GAT 7 KH 7 PI? .AD7 ANC 7 (MAIL_BOX, S) 

GATEKEEPER .AWAIT < M a I L_?OX , C, (t+2)) 

IF MAIL_BOX.MSG. INST = CMP ?X READY 
THEN 

IT - 0ST_GMP 

CASE DZLET 7 _ZI LE THEN F V _CMP_HNI EELETE_?ILE 
CASE C-E AT?_FILE THEM FM CMD_HND~CR 7 ATF~?ILE 
CAS 7 CR 7& T 7 LINE THEN FM CM 7 END CREAT?_LINK 
CAS 7 RZAD_FILE THEN ? W _CMD_END READ FILS 
CASE STORE 7 ILE THEN FM_CMD_HND 5T0?E_FIL2 
CASE R 7 AD_ a >L THEN 7 M_CMP_HND RS a D_ & CL 
CASE AIT_ACL_ENTRY THEN FM_CMD HNC AFD_ACL_SNTR Y 
CASE DELETE a CL_FNT !- Y THEN ?M_CMD HND_DSL 7 TF 1 CL ENTRY 
Cft SE ® T OHT T n7 N FM_CM 7 _HND_ 4r ORT 
ELSE 

MAIL_BOX. MSG. INST := ACK_HCST 
M ATL_ROX.MSG.? a THN 4 M F := NULL 
M.AIL_3CX.M3G.FILS_SIZ 7 := NULL 

MAIL SOX . MSG .SUC C CODE := EH HOP. CODE ( ILLEG L_C N 'D ) 
t := G a T 7 K 77 ? 7 R .TKXET (MAIL PCX, C) 

GATEKEEPER .ADVANCE (MAIL_30X, C) 

GATFKEFPEF. 6 '.‘/AIT (MAIL 30X . C. (t+2)) 

El 

ELSE 

MAIL BOX. MSG. INST := a C 7 HOST 
^ 6 1 L _30X .MS" . ? a THNA M 7 :=' NULL 
MAIL_30X .MSG ,FILE_S IZE := NULL 

MAIL_3CX.M5G.SUCC CODE := EPRO?._CODE ( CMD_?K_SX?SCTED ) 
t := GAT 7 KF 7 P 7 R. TICKET 'M. a lL_ROX, C) 

GATEKEEPER .ADVANCE (MAIL_BOX, C) 

GATS KEEPER . AW 4 IT (MAIL_?OX, C. (t+2)) 

FI 

OD 
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INTERNAL 
MSG = TYT 7 



FM_CMD_HND_DELETE_EILE PROCEDURE 
ENTRY 

MSG := D^L^T^IL^ 

DIR_CNTRL_DI RECTORY ( MSG 

USERID 
?A THNAM^ 

NULL !file_type! 

MULL !access_level! 

NULL ! 1 ink ! 

MULL) !acl_entry ! 

!retur r, s dir succ_cnde! 

I T DIR _Sl T C C_CC‘D V = TRUE 
THEN 

MAIL BOX. MSG. INST := ACX_HCST 
M«IL_?OX .MSG .PATHNAME := NULL 
MAIL_BCX .MSG .FILE_S IZE := NULL 
MAIL BOX. MSG. SUCC_CODE := FILE_DSLETED 
t := GATEK^PER. TICKET ( M AIL_POX , C) 

GATEKEEPER. ADVANCE (MAIL_3CX, C) 

GATEKEEPER. a WA IT (MAILJBOX. C, (t+2)) 

ELSE 

MAIL_3CX.MSG.IMST := ACK_HOST 
MAIL_BCX .MSG .PATHNAME := NULL 
MA.IL BOX .MSG.EILE_SIZ^ := NULL 

MAIL_3CX .MSG .SUCC_CODE := ERROR _C CDE ( DIR_SUCC_CODE ) 
!file not found; write access to directory 
not oe r-ni t ted ! 

t := GATEKEEPER. TICKET , MAIL_3CX, C) 

GATEKEEPER. "DV A MCE fMAIL_3CX, C) 

GATEKEEPER . AWAIT (M«ILJ>OX f C, (t+2)) 

El 

END FM CMD HMD DELETE FILE 
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^ILE PROCEDURE 



FM_CMD_F.ND_CF.E ATE 
ENTRY 

MSG := CFEATE_FI LE 
DlR_CNTRL_DI?ECTORY (MSG 

USER IP 
PATHNAME 
FILE TYPE 
AC(' 1? SS_LFV' C ’L 
NULL (link! 

NULL'' !acl_er.try! 

!returns dir_succ_code! 

IF BIR_SUCC_CODE = TRUE 
THEN 

MAIL_?CX .MSG .1 NST := aCKJTOST 
MAIL_3CX. MSG. PATHNAME := NULL 
MAIL_30X.MSG.FILE_SIZE := NULL 
MAIL_30X. M SG.S T JG r, _ r, 0P" r := 1? I L 1? _CRFATFD 
t := GATEKEFPK A .TICKET (MAIL_3CX, C) 

GATEKEEPER . aPYANCE (MAIL_30X, C) 

GATEKEEPER . s WAIT ^M«IL_' D 0X. C. <t+2)) 

ELSE 

MAIL_BOX .MSG . INST := aCK_HCST 
MA IL_ FOX .MSG.? a THNAMF : = NULL 
MAIL_BCX.MSG.FILE_SIZE NULL 

M A IL_30X . V SG . SUCC_C OPF : = ER?.OR_COPE t DIF_SUCC_COPE) 
! direct ory not found; write access to direc to ry 
ret permitted? directory full! 
t := GATEKEEPER. TICKET (MAIL_30X, C) 

GATFK x ' ,? P r R . a PV a NG’ 1 ’ (MAILJEOX, C) 

GATEKEEPER. AW A IT (MAIL_3CX, C , (t + 2)) 

FI 

K'JP FM C^P HNP C r F A T T FIL^ 
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EM CMD_CR7ATE_LT N r PROCEDURE 
ENTRY 

MSG i- CREATE_LI NX 
DIR_CNTRL_DI RECTORY (MSG 

USERID 

paten A ME 

NULL ! file type! 

NULL ! access level ! 

LINK 

NULL ) !acl_entry! 

Jretums dir_succ_code! 

IE DIR_SUCC_CODE = TEUF 

TRVN] 

MAIL_BOX. MSG. INST : = ACK_EOST 
MAIL_B0X. MSG .PATHNAME : = NULL 
'"'ILJPOX.MSG.^IL^SIZ*’ := NULL 
MAIL_3CX.MSG.SUCC_CCDE : = LI NK_CREATED 
t := GATEKEEPER. TICKET 'MAIL_30X, C) 

GA TEKEEPER . ! DV fi NC^ ' M *IL POX, 0) 

GATE KEEPER. AW A IT (MAIL_3CX, C 't+2)) 

ELS E 

M AIL_B0X .MSG .INST := »"K_HOST 
MAIL_3CX. MSG. PATHNAME := NULL 
MAIL_50X.MSG.7ILE_SIZF := NULL 

MAIL_POX . M SG .SUCC_COD 7 ? = ^RROR_CODE ( DIR_SUCC_CODE) 
!dir°ctory not found; write access to directory 
not permitted? directory full! 
t : = G A T T? E T,r ? T, R. TICKET (MAILBOX, C) 

GATEKEEPER. ADVANCE (M,AIL_3CX, C) 

GATEKEEPER. AW a IT (MAIL_30X, C. (t+2)) 

El 

END FM CMD HND CREATE LINK 



FM_CM.D_R.SAD FILE PROCEDURE 
ENTRY 

IF FIL 1? TY?' 1 ’ = PfiT 4 
THEN 

MSG := READ_FILE 
DIR CNTRL_P 4 T 6 (MSG 

USERID 
PATHN i ME 

NULL) ! f i le_s i z e ! 

Ireturns dir_succ_cods , d i r_oat hname , dir_file_si ze ! 

IF D I P_SUCC_CODE = TRUE 
T aT N 

MAIL_3CX.* /, SG.IMST := READ_FILE 

MA IL BOX. MSG. PATHNAME := DI R_PA TEN AMI 

444 1 IT? OX .MSG .EILS_SIZ T := DIR FILE_SIZS 

MAIL BOX. MSG. SUCC_CODV NULL 

t := GATEKEEPER .TICKET (M»IL_30X, C) 

GA TEKFt??ER . 4 DV 4 NC T (M 4 IL_P0X, C) 

GATEKEEPER. AWAIT (MAIL 30X, C, -t+2)) 

IF MAIL_30X.MSG.SUCC_C0DE = TRUE 
XREN 

MSG := UPDATE_READ 
DIE CNTRL UPDATE ( MSG 

US trip 
PATHNAME) 

! update will not fail! 

M4 1 L_ , OX . MSG . IM ST := ACK_HCST 
MAIL_30X . MSG . PATHNAME := NULL 
MAIL_30X . MSG .FILE_SI ZF. := NULL 
MAIL' OX . W SG .SUCC GOD" 7 •= R^AD COMPLETE 
t := GATEKEEPER .TICKET (MAIL_3CX, C) 

GATEKEEPER .ADVANCE (MAIL 30x7 C) 

CATEK^P'kR . 4 WAIT 'M 4 IL_'OX, C) 

ELSE 

MAIL_30X. MSG .INST := ACK HOST 
MAIL POX .MSG .PATHNAME := NULL 
MAIL_30X.MSG.FILE_SIZE : = NULL 

MA I L__BOX . MSG . SUCC_CODE := M AI L_30X .MSG . SUCC_CODS 
lerror code returned from io process! 

!file rot found by io process; 
file read aborted by write) 
file read aborted by file deletion; 
cm3 pac’-cet receive^! 
t := GATEKEEPER .TICKET (M 4 IL_30X, C) 

GAT '’KEEPER . 4 DV 4 NCE 'M 4 IL_3CX, C) 

GATEKEEPER .AWAIT (MAIL_30X, C, (t+2)) 

El 
E L S' 7 

MAIL_BOX .MSG .INST := 4 CK_HCST 
MAIL_?GX .MSG .?f THNamt? : = NULL 
MAIL_3CX. MSG. FILE SIZE := NULL 

MAIL_30X .MSG .SUCC _C ODE := ERROR _ CODE (D I E_SUCC_CODE ) 
Ifile not found) 

read access to file not permitted! 
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t := GATS T/ FEPEP .TICKET (M a IL_30X, C) 

GA . S PV » NCE /Ma IL_ ia OX., C) 

GATEKEEPER. AWAIT (MAIL_BOX, C, (t+2)) 

FI 
FLS F 

IF F ILS_TY?E = DIRECTORY 
THEN 

MSG := RE s D_DI R 

DIR CNTRL_DI RECTORY ( MSG 

USERID 
? A TRN a MR ) 

NULL lfile_type! 

NULL ! ac cess_Ievel ! 

NULL ! li nk ! 

NULL) !acl_entry! 

Iretur* 1 ? dir_succ_code ! 

IF DI R_SUCC_CODE = TRU 7 
THEN 

MAIL_BOX.MSG.INST := »CK_HOST 
M.a I L * OX .MSG. PATHNAME := NULL 
MAI L_3CX . V SG .FILE_S IZE := NULL 
MAIL_B0X.MS5.SUCC_.C0DE := DI.W.5AD ^COMPLETE 
!dir data transfered f ran 4ir_fcuffer; 
ack T ' owl ed verier t se n t! 
t, := GATEKEEPER .TICKET 'M a IL_BCX, C) 
rjaT?X*E?‘6'R. ADVA 'mail ^CXT C) 

GATEKEEPER .AWAIT 'MAIL_30X, C, (t+2)) 

ELSE 

”AIL 'OCX. MSG. INST := ACCOST 
MAI L_30X. MSG. PATHNAME : = NULL 
MAI L_ BOX .MSG .EILE_S TZE := NULL 

MAT L~?OX . M SG .SUGO_OODE ;=ERR0R_C0DZ (DIR_SUCC_COr v ) 
!di rectorv not f^urd, 

read access to directory not permitted! 
t •= G t'vvjvvovv .TI CKFT 'M a IL BOX, G ) 

GATEKEEPER. ADVANCE '■ MAIL 30x7 C) 

GATEKEEPER. AWAIT 'M a IL_BOX, C, (t+2)) 

El 

ELSE 

MSG := REA D _EN TRY_D A T a 
DIR CNTRL_DI RECTORY (MSG 

USERID 

PATHNAME 

NULL !file_type! 

NULL !access_level ! 

NULL ! 1 i r k ! 

NULL) !acl_entry! 

Ireturns d ir_succ_code ! 

IE DIF_SUCC_CODE = TRUE 

JUT? »\[ 

MAIL_BCX. MSG. INST := ACK_HOST 
MAI L_BOX. MSG. PATHNAME := NULL 
MAIL_?OX.MSG.EILE_SIZ p := NULL 
MAIL BOX.MSG.SUCC CODE := ENTRY READ COMPLETE 
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’entry data trar.sfered from dir_buffer* 
acknowledgement sent! 
t := GATEKEEPER. .TICKET 'MAIL_BCX, C) 

G S TEKEE?ER . a DV S NCF 'MAIL_BGX, C) 

GATEKEEPER .AWAIT (M.aiLJ’OX, C, (t+2)) 

^ T ^ ^ 

- ‘ J mstl_-dox .msg.INST := AGE_H05T 
MAIL_3CX.MSG ,?ATHNA M E := NULL 
MAIL_BOX.MSG.FILE_SIZE := NULL 

MAILJPOX .MSG .SUCC_rOP^ := ERROR_CODE (DIR_SUCC_CODE ) 
!file nnt found; read access to file not permitted! 
t := GATEKEEPER. TICKET (MAIL_BCX, C) 
f , .«T T ’K'PT?pTn i. st)V. ! Nr -11 (MAIL ^OX, C) 

GATEKEEPER .AWAIT (MAIL_30X, C, (t+2)) 

71 

El 

71 

END FM CMD HND READ FILE 
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FM_CMD_HND_STORF_FlLE PROCEDURE 
ENTRY 

MSG := STOP* T I L 17 
DIR_CNTRL_DAT 4 (MSG 

USER ID 

P a-pa-^A M -51 

FILE_S IZE) 

Jreturns di r_Pa thname ? dir_succ_ccde ! 

IF DiR_sunc_ n c^ = TRUE 
THEN 

MAIL _BOX . MSG . I NST := STORE_FILE 
MA IL_30X .MSG .paT^NAM 1 ? •= DIR_?ATHNAMF 
MAIL_3CX.MSG .FILE_S IZE := FILE_SIZE 
MAIL _B OX. MSG .5UCC_CODF := NULL 
t ; = C- ft T T K TX 'P 1: 'R .TICFFT / MAIL_30X, 0 ) 

GATEKEEPER. ADVANCE (MAIL_BOX, C) 

GATEKEEPER. 4 V 4 IT (MAIL_30X, C, (t+2)) 

IT- M 4 1 L_POX .MSG.SUCC_f’OD 1? = TRU E 
THEN 

MSG ?= U?DATE_STORE 
DIR CNTRL UPDATE 'MSG 

USERID 

PATHNAME) 

Jupdate will not fail! 

MAIL_3CX. MSG. INST := ACK_HOST 

MAIL_BOX. MSG. PATHNAME := NULL 

MA IL~3CX .MSG ,FTLF_SI Z v : = NULL 

MAIL BOX . M SG .SUCC_CCDF := STCRE_COMPL±TE 

t := G ATEXFBPE- .TICKET (MAIL_30X, C) 

GATEKEEPER . 4 DV A NC' 5 ’ ^ 4 IL T OX, C) 

GATEKEEPER. AWAIT (MA I L_3CX , * C , (t*2)) 

ELSE 

M AIL_?OX . M SG .INST := 4 CK u OST 
MAIL_30X .MSG .PATEN 4 ME := NULL 
MA IL_?OX .MSG .FILF_ST Z^ := NULL 

MAIL_3CX .MSG .SUCC_COD^ := M AI L_30X .MSG . SUCC_C CDF 
!error returned from io process) 

cmd packet received: improper number of data packets! 
t := GATEKEEPER. TICKET (MAIL_30X, C) 

GATEKEEPER. "-DVANCE 'MAIL_BOX. C) 

GATEK^^P^R . 4 V/AIT (M 4 IL_30X, C, (t+2)) 

FI 

ELSE 

M AIL_30X .MSG. INST := ACK_HOST 
MAIL_BOX. MSG. PATHNAME := NULL 
M 4 IL_30X .MSG . FILE_S IZE := NULL 

MAIL_POX.MSG .SUCC_rODF := ^RROR_CODE ( DIR_SUCC_CODE) 
!file not found? write access to file not permitted! 
t GATEKEEPER. TICKFT f MA IL_EOX , C) 

GATEKEEPER . 4 GV 8 N^^ ( y4 IL POX, G) 

GATEKEEPE^ .AWAIT (MAIL 30X,' C, (t+2) ) 

FI 

END FM CMD HND STOR ? FIL' 5 ’ 
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FM_CMD_END_RF* D _ 4 C L PROCEDURE 
ENTRY 

MSG r = F.E AD_ 4 CL 

DIR CNTRL_DIR Tn TORY ( MSG 

USERID 

PATHNAME 

NULL !file type! 

NULL !access level! 

NULL ! link ! 

NULL ' ! a c 1 _e n t r y ! 

Jreturns dir succ_code! 

IF DIR_SUC C_CODE = TRUE 
THEN 

MAIL BOX. MSG. INST := ACE HOST 
M.AIL - BOX .MSG .PATHNAME := NULL 
MAIL_?OX .MSG . EILE_SIZ" 7 := MULL 
MAIL_BCX .MSG . SUCC_COEE := A CL_READ_ COMPLETE 
!acl data trar.sfered from acl_buffer? 
host acknowledgement sent! 
t : = GATEKEEPER .TICKET 'MAIL_30X, C) 

GATEKEEPER . P DV"NCE (M 4 IL_BCX. C) 

r. & t^K^EP - 7 ?. . A W 5 1 T (MAIL ^OX , C, (t + 2)) 

ELSE 

MAIL_BOX. MSG. INST := AC r POST 
MAIL POX .MSG .? 4 TPNAME NULL 
M AIL~30X .MSG .EILE_SIZE := NULL 

MAIL_EOX .MSG . SUCC_CODE := FRRO?._CODE (DIR_SUCC_CODE ) 
!file not found? read access to directory file 
rot per^i 1 1 9 d j 

t := GATEKEEPER .TICKET 'MAIL_30X, C) 

GAT^K^PER . »DVANGR (m 4 IL_?CX. C) 

GATEKEEPER. AWAIT (MAIL_BOX, C, (t+2)) 

FI 

END FM C M D HMD ?E 4 D JCL 



113 



vm CMD HMD ADD ir L 7 NTRY PROCEDURE 
ENTRY 

MSG := ADD ACL_ENT?Y 
DIR_CNTRL_DI RECTORY (MSG 

USERID 

PATHNAME 

MULL ! f ile type! 

MULL !access level! 

MULL !lipk! 

«CL_^NTRY ) 

! returns dir succ_code! 

IF DIR_SUCC_CODE = TRUE 
THEM 

M AIL_BCX . M SG . I NST := ACK_EOST 
MA IL_BOX . MSG . PATHNAME != NULL 
MAIL POX. MSG. FILF_SIZF := NULL 
MAIL_30X.MSG.SUCC_CCDE := AC L_S M TR Y _AEDSD 
t : = GATEKEEPER. .TICKET ( MA IL_BOX, C) 

GATEKEEPER . A DV 8 NO 7 ^M 8 -IL PCX, C ) 

GATEKEEPER. AWAIT (MAIL_30X, C, ( t -2 ) ) 

ELSE 

M A TL_RGX . M SG . I NS T := ACK_HOST 
M AIL_30X .MSG .PATHNAME := NULL 
M J IL_30X.MSG.EILE_SIZE : = MULL 

MAIL_?OX. M SG.SUCC_CODE t= T RR0R_CCPE (DIR_SUCC_CODE) 
! file ro* found? wr i t e acces s to directory not 
permitted? acl_er.try "uool” entity! 
t ;= G A T^K^^P^R .TICKET 'MAIL ^OX , C) 

GATEKEEPER .ADVANCE (MAIL_BOX, C) 

GATEKEEPER . »W AIT (MAIL BOX, C, (t+2)) 

FI 

END FM CMD HMD ADD ACL ENTRY 
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EM CMD_HMD DELETE_ACL_ENTA Y PROCEDURE 
ENTRY 

vg C := £ rip t "• p L ''’NTRY 

DIR_CNTRL_D I RECTORY (MSG 

USERID 

PATHNAME 

NULL ! f il e_ty?e ! 

NULL !access level ! 

NULL ! 1 irk ! 

ACL_ENTRY ) 

!returns di r_succ_r ode ! 

IE DIR_SUCC_COE^ = TRU 17 
THEN - 



MAIL_B0X.MSG.INST := ACK_HCST 

M 4 IL_ROX .MSG .piTEN®^ 17 := NULL 

MAIL_ROX.MSC.EILE SIZE := NULL 

MAIL BOX . MSG . SUCC~COBE := A CL_E NT? Y_DELETED 

l T T ’E r ‘ r ?' r R -TICKET 'M»IL ^OX, C) 

GATEKEEPER. ADVANCE (MAIL_'°0X7 C) 

GATEKEEPER . AW&IT (M«IL_30X, C, ( t *2)) 

ELSE 

MAIL_30X. MSG. INST := »CE_HOST 

MAIL_3CX .MSG. PATHNAME := NULL 

M A IL_RCX .MSG .El L^S IZ’ 7 •= NULL 

MAIL BOX , M SG.SUCC CODE : = ERROR CODE (DIR_SUCC 



write access to directory rot 

) 



El 



!fils not found? 
nermitted ! 

t* := GATEKEEPER .TICKET 'MAIL_BOX, 
GATEKEEPER . a DV S NCE (M 1 IL_3CX, C) 

G ATEKETp^R . »W? IT (MAIL ^CX , C, (t+2)) 



END FM CMD HND DELETE «CL ENTRY 



CODE ) 
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FM_CMD HND_A T} ORT PROCEDURE 
ENTRY 

MSG := A ^ORT 

DIP CNTRL_UPDATE ( MSG 

USERID 

PATHNAVp) 

Istore c^d re°ds t,n free terporary file 
MAIL *OX. MSG. INST := ACKJUDST 
MAIL~30X. MSG. PATHNAME := NULL 
M A IL_BOX . MSG .EILE_SIZE := NULL 
MAI L_?CX . MSG . SU^C CODE : = CMD_ J ?ORTED 
t := GATEKEEPER .TICKET (MAIL_BOX, C) 
GATEKEEPER. ADVANCE 'MAIL_ROX, C) 
GATEK T ’ T ? T R . 4 W 4 IT (MAH ‘COX, C, f t+2)) 
END FM_CMD_END_ ABORT 

END EM COMMAND HANDLER 
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IC COMMANE HANDLER MODULE 



EXTERNAL 



PE HND STORE PROCEDURE (S^G # 

SIZE 

RETURNS CPK SUCC CODE 



LWORD 

DWORD) Inumber cf bits! 
•9 yte ) 



PK_HND_SEND PRO^OTJRE ( S*G_# DWORD 

SIZE DWORD) 

RETURNS ■ ?E_SUCC_OODE ^YTE) 

PE HND ACK HOST PROCEDURE ( M SG 3YTE ) 



PILE RND_SEND_EILE PROCEDURE (PATHNAME 
RETURNS (FILE SUCC CODE 



! rubber cf bits 



STRING 

BYTE) 



EIDE_HND_STOFE_EI LE PROCEDURE (? a THN a ME 
RETURNS ( FILE SUCC CODE 



STRING ) 
3YTE ) 



INTERN AD 



10 CMD HMD ?ROC T 'UUR 1 *’ 

ENTRY 

t := TICKET (M a IL_R0X, C^ 

AWAIT (Ma I D_' c OX , C, It-^l)' 

DC 

IE MAIDJBOX .MSG. INST 

CAS V R^D C W D T^N PE R va D CME 

case ack Host then ?k~hnd“ack _5cst 

^M 4 IL_30X.MSG.SUCC_C0DZ) 
0 s SE S’ ? NU_EI TH^N ' r IDE_END_REA D_EI LF 

(MAIL_3CX. MSG. PATHNAME 

(maid_rox.msg. eide_s I ze) 

r«SE STCR r ’_ T 'I DE THEM T I L T '_HN T '_ST0RE_" 5 ’I DE 

[ MA I L_30X .MSG. PATHNAME 
MAID_ROX .MSG .FILE_SIZE) 
El 

t := TICKET ( M AIL_EOX, C) 

ADVANCE ( M A IL_30X , C) 

AWAIT ( M AI L_POX , C, ((t *? ) 

CD 

END I0_ CMD_HND 



END 10 COMM 4 ND ^ANDL^P. 
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